RFR: 8339725: Concurrent GC crashed due to GetMethodDeclaringClass [v2]

Stefan Karlsson stefank at openjdk.org
Mon Sep 9 20:02:04 UTC 2024


On Mon, 9 Sep 2024 06:04:36 GMT, Liang Mao <lmao at openjdk.org> wrote:

>> Hi,
>> 
>> It's a fix for 8339725. I think getting the oop from Klass::java_mirror() should use a ON_PHANTOM_OOP_REF decorator here which could make sure the oop would be kept alive in concurrent marking and return nullptr while in concurrent reference processing and unloading.
>> 
>> test/hotspot/jtreg/runtime and gc are clean.
>> 
>> Thanks,
>> Liang
>
> Liang Mao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix build error in windows/mac

When me, Erik, and Axel, discussed this earlier today, we thought that the correct fix would be to add a klass_holder() call to GetMethodDeclaringKlass(). That works as long as there's no safepoint between that and the creation of the JNI handle, which there isn't.

I also think that we should add a comment to GetFieldDeclaringClass, explaining why the klass is held alive.

I'd also prefer if we added an `assert(k->is_loader_alive(), "Must be alive")` to `get_jni_class_non_null`. That assert will trigger if the call gets called just after ZGC marking, but before the jmethodID cleaning. A short window, but maybe enough to catch these kind of errors earlier.

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

PR Comment: https://git.openjdk.org/jdk/pull/20907#issuecomment-2338970316


More information about the hotspot-dev mailing list