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

Zhengyu Gu zgu at openjdk.java.net
Wed Nov 10 13:11:37 UTC 2021

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 ([0248f1e](https://github.com/openjdk/jdk/commit/0248f1e4cd6a8311f0532c637a31bd71c9041451)), but surely the assert `ShenandoahCodeRoots::unregister_nmethod` can also be called at safepoint without `CodeCache_lock` held?

It seems possible during [STW unloading](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/parallelCleaning.cpp#L81) although previous version passed GHA

I will take a further look in separate CR see if we can cleanup a bit.


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

More information about the hotspot-gc-dev mailing list