RFR(L): 8046809: vm/mlvm/meth/stress/compiler/deoptimize CodeCache is full.
albert.noll at oracle.com
Wed Oct 22 09:52:25 UTC 2014
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?
> 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!)
> 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.
Here is the webrev with the updated comments.
> — John
More information about the hotspot-compiler-dev