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

David Holmes dholmes at openjdk.org
Wed Sep 11 02:18:13 UTC 2024


On Tue, 10 Sep 2024 10:15:43 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:
> 
>   Exclude libagent8339725.cpp compiling for windows

So what exactly is the robustness fix being proposed here? The jMethodID is not a means to keep alive a class, and so we have an invalid one. Are we just trying to avoid a crash (in which case how are we reporting that the jMethodID is in fact invalid)? or are we actually making the jMethodID keep the class alive, contrary to the JNI Specification?

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

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


More information about the hotspot-dev mailing list