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