RFR: 8276801: gc/stress/CriticalNativeStress.java fails intermittently with Shenandoah [v2]

Zhengyu Gu zgu at openjdk.java.net
Tue Nov 9 17:46:38 UTC 2021


On Tue, 9 Nov 2021 16:29:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert assertion for unregister_nmethod
>>  - Fix comment as Aleksey suggested
>
> src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp line 119:
> 
>> 117: 
>> 118: void ShenandoahCodeRoots::unregister_nmethod(nmethod* nm) {
>> 119:   assert(CodeCache_lock->owned_by_self(), "Must have CodeCache_lock held");
> 
> I don't understand this change.
> 
> This method is called from:
> 
> 
>    // Unregister must be done before the state change
>   {
>     MutexLocker ml(SafepointSynchronize::is_at_safepoint() ? NULL : CodeCache_lock,
>                      Mutex::_no_safepoint_check_flag);
>     Universe::heap()->unregister_nmethod(this);
>   }
> 
> 
> ...which would mean we _do not_ hold the `CodeCache_lock` at safepoint? Previous assert captured that fact. New one does not. Shouldn't this assert fail intermittently? Same goes for `register_nmethod`, `flush_nmethod`, probably.

Good catch! I revert the assertion in ShenandoahCodeRoots::unregister_nmethod().

Above code is racy, because there can be a drive-by safepoint when the test is performed. However, it is not problem, because Shenandoah (so as ZGC) only tags the nmethod is unregistered. 

It is not true for flush_nmethod(), where `CodeCache_lock` must be held.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6316


More information about the hotspot-gc-dev mailing list