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

[Liang Mao]

On Wed, 11 Sep 2024 04:23:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

> so the loader must be alive at this point but could be unreferenced. How is the loader allowed to become not-alive after this check, whilst within GetMethodDeclaringClass? The current thread is _thread_in_vm so not safepoint safe, so no safepoint can occur. Does the GC allow it to become not-alive / get unloaded, concurrently with the execution of code like this? 

Yes. `GetMethodDeclaringClass` is runnning in state of `_thread_in_vm` but it returns JNI handle with class into user native code then thread will be in `_thread_in_native` and GC can still go into end of marking and do reference processing and class unloading. 

> If so then that could have happened before we call klass_holder() and create the Handle here couldn't it:

Klass* k = method->method_holder();
Handle holder(Thread::current(), k->klass_holder()); // keep the klass alive

Inside "JvmtiEnv::GetMethodDeclaringClass" we call `klass_holder` to keep it alive in the thread state of `_thread_in_vm` which guarantees the safety.

> General question: if k->klass_holder() keeps the class alive, at what point do we "release" this such that class can become not-alive again?

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

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

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