[9] RFR(L): 8046809: vm/mlvm/meth/stress/compiler/deoptimize CodeCache is full.

[Albert Noll]

Hi John

Thanks for the review. Please see comments inline:


On 10/21/2014 10:00 PM, John Rose wrote:
> On Oct 16, 2014, at 1:33 AM, Albert Noll <albert.noll at oracle.com> wrote:
>
>> Can I have a second review?
> Reviewed.
>
> Question:  Can you say why "handle_full_code_cache" doesn't need to be called so much anymore?
> It seems a non-trivial issue since you were able to delete it from so many places, but not all.
> I suggest adding a comment to the header of handle_full_code_cache to guide future coders where the calls must be put.
handle_full_code_cache() is now only called from within the code cache. 
Since we consistently handle a full code cache, there is no need to put 
the same code at every call site. I though about moving 
handle_full_code_cache to the code cache (and make it private). However, 
the actions that are taken impact compilation, so overall, I think, 
having handle_full_code_cache is better kept in CompileBroker.

I'll update the comment.
> A couple of typos:
>
>    + "Start aggressive sweeping if X[%] of the code cache are free."   \
> s/are/is/ (percentage of singular is singular as in, 5% of code cache is full, etc.)
>
>   + init_log_sweeer
> s/sweeer/sweeper/; IMO should actually be "init_records", "init_log", or "init_sweeper_log".
> (Sweeering is not done in polite company!)
Fixed.
> I like the cleanups.  Lots of tidying, code deletion, and factoring.
> You have taken a hard part of the JVM and made it incrementally simpler and nicer to work with.
Thanks!

Here is the webrev with the updated comments.
http://cr.openjdk.java.net/~anoll/8046809/webrev.06/

Best,
Albert
> Thanks,
> — John