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

Coleen Phillimore coleenp at openjdk.org
Mon Sep 9 16:32:05 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

Okay I agree that you can't use a Handle to reference this mirror if it's not already referenced by other code (already alive).  Fetching out of the CLD::_handles doesn't keep it alive.

    // method - pre-checked for validity, but may be null meaning obsolete method
    // declaring_class_ptr - pre-checked for null
    jvmtiError
    JvmtiEnv::GetMethodDeclaringClass(Method* method, jclass* declaring_class_ptr) {
      NULL_CHECK(method, JVMTI_ERROR_INVALID_METHODID);
      (*declaring_class_ptr) = get_jni_class_non_null(method->method_holder());
      return JVMTI_ERROR_NONE;
    } /* end GetMethodDeclaringClass */

So here, I don't see anything holding the method_holder() mirror through the Method, unless it's in the caller (a global jobject or something).  Same with the GetFieldDeclaringClass function.

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

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


More information about the hotspot-dev mailing list