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

[Albert Noll]

Hi Vladimir,

thanks for your feedback. Yes, it is possible that a non-compiler thread 
calls
'possibly_sweep()'. E.g., 'create_native_wrapper()' can be called by a 
non-compiler
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.

Best,
Albert

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
>>
>>
>>