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

[Aleksey Shipilev]

On Tue, 9 Nov 2021 17:33:04 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> JDK-8276205 fixed a bug that prevents concurrent code cache iteration, without holding CodeCache_lock. That causes register_nmethod() calls can go through during concurrent code cache iteration.
>> 
>> This is no a problem for new nmethod, cause it is *not* in cache cache snapshot for concurrent code cache iteration, but *nmethod patching* is. We can not allow *nmethod patching* during concurrent code cache iteration, should block it until iteration is completed.
>> 
>> Test:
>> 
>> - [x] hotspot_gc_shenandoah
>> - [x] Stress test on gc/stress/CriticalNativeStress.java
>
> 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

I still do not understand about `ShenandoahCodeRoots::unregister_nmethod` here. You seem to have restored the assert in the nmethod-table (https://github.com/openjdk/jdk/pull/6316/commits/0248f1e4cd6a8311f0532c637a31bd71c9041451), but surely the assert `ShenandoahCodeRoots::unregister_nmethod` can also be called at safepoint without `CodeCache_lock` held?

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

Changes requested by shade (Reviewer).

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