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

Okay, so we have:

jvmti_GetMethodDeclaringClass(jvmtiEnv* env,
            jmethodID method,
            jclass* declaring_class_ptr) {

which does:

 Method* checked_method = Method::checked_resolve_jmethod_id(method);
  if (checked_method == nullptr) {
      return JVMTI_ERROR_INVALID_METHODID;
  }
  if (declaring_class_ptr == nullptr) {
      return JVMTI_ERROR_NULL_POINTER;
  }
  err = jvmti_env->GetMethodDeclaringClass(checked_method, declaring_class_ptr);

and in `checked_resolve_jmethod_id` we have:

  // If the method's class holder object is unreferenced, but not yet marked as
  // unloaded, we need to return null here too because after a safepoint, its memory
  // will be reclaimed.
  return o->method_holder()->is_loader_alive() ? o : nullptr;

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?  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

??

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?

BTW this seems a general problem that might impact any JVMTI function that has performed the above safety-check and then gone on to use the Method and its holder class.

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

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