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
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
>>
>>
>>
More information about the hotspot-compiler-dev
mailing list