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

[David Holmes]

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

I think you are missing my point:

Klass* k = method->method_holder();
// Why can't k already be not-alive here?
Handle holder(Thread::current(), k->klass_holder()); // keep the klass alive


> In next GC, the class could be unloaded if the JNI handle with class is released.

Again this misses my point. If calling `k->klass_holder()` keeps `k` alive, what do we need to do to undo that? I assume there must be some kind of reference count in relation to this. ??

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

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