RFR(XS): 8028306: nsk stress tests, CodeCache fills, then safepoint asserts

Albert Noll albert.noll at oracle.com
Thu Nov 14 02:58:27 PST 2013

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:
> Albert,
> Thanks for fixing that. Missed that case when added 
> No_Safepoint_Verifier.
> 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:
>> Hi,
>> 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,
>> handle_full_code_cache
>>                     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,
>> Albert

More information about the hotspot-compiler-dev mailing list