Found while trying to stress metaspace.
Seems like the issue is that the MultiArray_lock is taken to make the array klass creation atomic. However if ObjArrayKlass::allocate_objArray_klass fails to allocate due to metaspace exhaustion and JVMTI JVMTI_EVENT_RESOURCE_EXHAUSTED is enabled Metaspace::report_metadata_oome will try to call into java, with MultiArray_lock held.
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (/scratch/aboldtch/jdk/open/src/hotspot/share/runtime/interfaceSupport.inline.hpp:187), pid=732125, tid=1579048
# assert(!thread->owns_locks()) failed: must release all locks when leaving VM
#
# JRE version: Java(TM) SE Runtime Environment (21.0) (fastdebug build 21-internal-LTS-2023-05-15-1851326.aboldtch...)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 21-internal-LTS-2023-05-15-1851326.aboldtch..., mixed mode, sharing, tiered, compressed class ptrs, z gc, linux-amd64)
# Problematic frame:
# V [libjvm.so+0x11c39fc] JvmtiJavaThreadEventTransition::JvmtiJavaThreadEventTransition(JavaThread*)+0x21c
Relevant stack trace:
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x11c39fc] JvmtiJavaThreadEventTransition::JvmtiJavaThreadEventTransition(JavaThread*)+0x21c (interfaceSupport.inline.hpp:187)
V [libjvm.so+0x11bdd7b] JvmtiExport::post_resource_exhausted(int, char const*)+0x14b (jvmtiExport.cpp:1781)
V [libjvm.so+0x13c49fd] Metaspace::report_metadata_oome(ClassLoaderData*, unsigned long, MetaspaceObj::Type, Metaspace::MetadataType, JavaThread*)+0x41d (metaspace.cpp:972)
V [libjvm.so+0x13c4c35] Metaspace::allocate(ClassLoaderData*, unsigned long, MetaspaceObj::Type, JavaThread*)+0xc5 (metaspace.cpp:922)
V [libjvm.so+0x12053c2] Klass::initialize_supers(Klass*, Array<InstanceKlass*>*, JavaThread*)+0x3b2 (array.inline.hpp:36)
V [libjvm.so+0x639761] ArrayKlass::complete_create_array_klass(ArrayKlass*, Klass*, ModuleEntry*, JavaThread*)+0x21 (arrayKlass.cpp:105)
V [libjvm.so+0x146e046] ObjArrayKlass::allocate_objArray_klass(ClassLoaderData*, int, Klass*, JavaThread*)+0x3f6 (objArrayKlass.cpp:127)
V [libjvm.so+0xe5a423] InstanceKlass::array_klass(int, JavaThread*)+0xe3 (instanceKlass.cpp:1481)
V [libjvm.so+0xe5dbfb] InstanceKlass::allocate_objArray(int, int, JavaThread*)+0x23b (instanceKlass.cpp:1406)
V [libjvm.so+0x14ac1e7] oopFactory::new_objArray(Klass*, int, JavaThread*)+0xe7 (oopFactory.cpp:122)
V [libjvm.so+0xea06d9] InterpreterRuntime::anewarray(JavaThread*, ConstantPool*, int, int)+0xf9 (interpreterRuntime.cpp:256)
Seems like the issue is that the MultiArray_lock is taken to make the array klass creation atomic. However if ObjArrayKlass::allocate_objArray_klass fails to allocate due to metaspace exhaustion and JVMTI JVMTI_EVENT_RESOURCE_EXHAUSTED is enabled Metaspace::report_metadata_oome will try to call into java, with MultiArray_lock held.
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (/scratch/aboldtch/jdk/open/src/hotspot/share/runtime/interfaceSupport.inline.hpp:187), pid=732125, tid=1579048
# assert(!thread->owns_locks()) failed: must release all locks when leaving VM
#
# JRE version: Java(TM) SE Runtime Environment (21.0) (fastdebug build 21-internal-LTS-2023-05-15-1851326.aboldtch...)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 21-internal-LTS-2023-05-15-1851326.aboldtch..., mixed mode, sharing, tiered, compressed class ptrs, z gc, linux-amd64)
# Problematic frame:
# V [libjvm.so+0x11c39fc] JvmtiJavaThreadEventTransition::JvmtiJavaThreadEventTransition(JavaThread*)+0x21c
Relevant stack trace:
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x11c39fc] JvmtiJavaThreadEventTransition::JvmtiJavaThreadEventTransition(JavaThread*)+0x21c (interfaceSupport.inline.hpp:187)
V [libjvm.so+0x11bdd7b] JvmtiExport::post_resource_exhausted(int, char const*)+0x14b (jvmtiExport.cpp:1781)
V [libjvm.so+0x13c49fd] Metaspace::report_metadata_oome(ClassLoaderData*, unsigned long, MetaspaceObj::Type, Metaspace::MetadataType, JavaThread*)+0x41d (metaspace.cpp:972)
V [libjvm.so+0x13c4c35] Metaspace::allocate(ClassLoaderData*, unsigned long, MetaspaceObj::Type, JavaThread*)+0xc5 (metaspace.cpp:922)
V [libjvm.so+0x12053c2] Klass::initialize_supers(Klass*, Array<InstanceKlass*>*, JavaThread*)+0x3b2 (array.inline.hpp:36)
V [libjvm.so+0x639761] ArrayKlass::complete_create_array_klass(ArrayKlass*, Klass*, ModuleEntry*, JavaThread*)+0x21 (arrayKlass.cpp:105)
V [libjvm.so+0x146e046] ObjArrayKlass::allocate_objArray_klass(ClassLoaderData*, int, Klass*, JavaThread*)+0x3f6 (objArrayKlass.cpp:127)
V [libjvm.so+0xe5a423] InstanceKlass::array_klass(int, JavaThread*)+0xe3 (instanceKlass.cpp:1481)
V [libjvm.so+0xe5dbfb] InstanceKlass::allocate_objArray(int, int, JavaThread*)+0x23b (instanceKlass.cpp:1406)
V [libjvm.so+0x14ac1e7] oopFactory::new_objArray(Klass*, int, JavaThread*)+0xe7 (oopFactory.cpp:122)
V [libjvm.so+0xea06d9] InterpreterRuntime::anewarray(JavaThread*, ConstantPool*, int, int)+0xf9 (interpreterRuntime.cpp:256)
- relates to
-
JDK-8213834 JVMTI ResourceExhausted should not be posted in CompilerThread
- Resolved
-
JDK-8327737 KlassTrainingData is allocated while holding a Mutex
- Resolved
-
JDK-8316427 Duplicated code for {obj,type}ArrayKlass::array_klass
- Resolved
(1 links to)