RFR(XS): 8028306: nsk stress tests, CodeCache fills, then safepoint asserts
vladimir.x.ivanov at oracle.com
Thu Nov 14 04:59:10 PST 2013
Thanks for clarifications.
Look good to me (not a Reviewer).
On 11/14/13 2:58 PM, Albert Noll wrote:
> Hi Vladimir,
> thanks for your feedback. Yes, it is possible that a non-compiler thread
> 'possibly_sweep()'. E.g., 'create_native_wrapper()' can be called by a
> thread ('sharedRuntime.cpp') and calls 'handle_full_code_cache()' which
> in turn
> 'calls possibly_sweep()'.
> I added the check, since I encountered a failing assert (example above)
> that checks
> that only compiler threads call the sweeper. I think it is fine to have
> the check in there
> since we only possibly sweep.
> On 11/14/2013 11:36 AM, Vladimir Ivanov wrote:
>> Thanks for fixing that. Missed that case when added
>> ciEnv.cpp: looks good.
>> sweeper.cpp: is it possible NMethodSweeper::possibly_sweep is called
>> in non-compiler thread? Why don't you turn the check into assert?
>> Best regards,
>> Vladimir Ivanov
>> On 11/14/13 1:36 PM, Albert Noll wrote:
>>> could I have reviews for this small patch?
>>> webrev: http://cr.openjdk.java.net/~anoll/8028306/webrev.00/
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8028306
>>> problem: 1) ciEnv::register_method() calls
>>> CodeCache::handle_full_code_cache() in a
>>> block where no safepoints are allowed. However,
>>> can reach a safepoint since it uses locks.
>>> 2) I added a check in 'possibly_sweep()' that ensures
>>> that only compiler threads
>>> can sweep the code cache. It can happen that normal
>>> Java threads can call
>>> 'possibly_sweep()' via 'handle_full_code_cache()'.
>>> solution: 1) move call to 'handle_full_code_cache()' outside the block
>>> where no safepoints
>>> are allowed
>>> 2) see above
>>> testing: failing test case passes.
>>> Many thanks in advance,
More information about the hotspot-compiler-dev