JDK-8010719 : NPG: The metaspace memory pools acquires Metaspace allocation lock out of order with Service_lock
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs25
  • Priority: P2
  • Status: Resolved
  • Resolution: Cannot Reproduce
  • OS: generic
  • CPU: generic
  • Submitted: 2013-03-25
  • Updated: 2013-05-22
  • Resolved: 2013-05-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
hs25 b91Resolved
Related Reports
Relates :  
JDK-8010818 - NPG: Remove metaspace memory pools
Description
The tests in nsk/monitoring/MemoryPoolMBean/ triggers the following assert:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/jprt/T/P1/151109.ehn/s/src/share/vm/runtime/mutex.cpp:1318), pid=28511, tid=140047208359680
#  fatal error: acquiring lock Metaspace allocation lock/5 out of order with lock Service_lock/1 -- possible deadlock
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b81) (build 1.8.0-ea-fastdebug-b81)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b24-internal-201303221511.ehn.hotspot-fastdebug mixed mode linux-amd64 compressed oops)
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread (0x0000000002421800):  JavaThread "main" [_thread_in_vm, id=28515, stack(0x00007f5f480b2000,0x00007f5f481b3000)]

Stack: [0x00007f5f480b2000,0x00007f5f481b3000],  sp=0x00007f5f481b0f80,  free space=1019k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xd97c02]  VMError::report_and_die()+0x302
V  [libjvm.so+0x67b120]  report_fatal(char const*, int, char const*)+0x80
V  [libjvm.so+0xb14165]  Monitor::set_owner_implementation(Thread*)+0x225
V  [libjvm.so+0xad4d4a]  SpaceManager::sum_used_in_chunks_in_use() const+0x2a
V  [libjvm.so+0xad4f1c]  MetaspaceAux::used_in_bytes(Metaspace::MetadataType)+0x4c
V  [libjvm.so+0xacaf9d]  MetaspacePoolBase::get_memory_usage()+0x2d
V  [libjvm.so+0xa4dadb]  LowMemoryDetector::detect_low_memory(MemoryPool*)+0x6b
V  [libjvm.so+0xa8a6cf]  jmm_SetPoolThreshold+0x23f
C  [libmanagement.so+0x4985]  Java_sun_management_MemoryPoolImpl_setUsageThreshold0+0x85
j  sun.management.MemoryPoolImpl.setUsageThreshold0(JJ)V+0
j  sun.management.MemoryPoolImpl.setUsageThreshold(J)V+165
j  nsk.share.monitoring.MemoryMonitor.setUsageThreshold(Ljava/lang/Object;J)V+37
j  nsk.monitoring.MemoryPoolMBean.getUsageThreshold.getthreshold001.test(Lnsk/share/monitoring/MemoryMonitor;Ljava/lang/Object;JLnsk/share/Log;)V+27
j  nsk.monitoring.MemoryPoolMBean.getUsageThreshold.getthreshold001.run([Ljava/lang/String;Ljava/io/PrintStream;)I+154
j  nsk.monitoring.MemoryPoolMBean.getUsageThreshold.getthreshold001.main([Ljava/lang/String;)V+6
v  ~StubRoutines::call_stub
V  [libjvm.so+0x874e8e]  JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x17fe
V  [libjvm.so+0x89bf65]  jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*)+0x535
V  [libjvm.so+0x89cf89]  jni_CallStaticVoidMethod+0x1f9
C  [libjli.so+0x7e24]  JavaMain+0x844

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  sun.management.MemoryPoolImpl.setUsageThreshold0(JJ)V+0
j  sun.management.MemoryPoolImpl.setUsageThreshold(J)V+165
j  nsk.share.monitoring.MemoryMonitor.setUsageThreshold(Ljava/lang/Object;J)V+37
j  nsk.monitoring.MemoryPoolMBean.getUsageThreshold.getthreshold001.test(Lnsk/share/monitoring/MemoryMonitor;Ljava/lang/Object;JLnsk/share/Log;)V+27
j  nsk.monitoring.MemoryPoolMBean.getUsageThreshold.getthreshold001.run([Ljava/lang/String;Ljava/io/PrintStream;)I+154
j  nsk.monitoring.MemoryPoolMBean.getUsageThreshold.getthreshold001.main([Ljava/lang/String;)V+6
v  ~StubRoutines::call_stub
Comments
The methods (used_words_slow() and capacity_words_slow()) that were being called and that did the locking that resulted in the lock ordering problem are no longer being called at places which will conflict with the Service_lock. If used_words_slow() and/or capacity_words_slow() are in fact needed when their use will conflict with the Service_lock, reopen this bug.
22-05-2013