JDK-7196045 : Possible JVM deadlock in ThreadTimesClosure when using HotspotInternal non-public API.
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: 6u33
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2012-09-04
  • Updated: 2021-06-01
  • Resolved: 2012-09-20
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.
JDK 6 JDK 7 JDK 8 Other
6u38Fixed 7u40Fixed 8Fixed hs20.13Fixed
Related Reports
Duplicate :  
JDK-6977180 - fatal error: acquiring lock Heap_lock/17 out of order with lock Threads_lock/15, mutex.cpp:1293
Relates :  
JDK-8266337 - ThreadTimesClosure doesn't handle exceptions properly
Description
SHORT SUMMARY: hang in sun.management.HotspotInternal
INDICATORS: JVM lockup, ThreadTimesClosure::do_thread creating String
COUNTER INDICATORS:
TRIGGERS: calling sun.management.HotspotInternal, and hitting a GC
KNOWN WORKAROUND: none
PRESENT SINCE:
HOW TO VERIFY:
NOTES FOR SE: ThreadTimesClosure::do_thread called with Threads_lock, must 
avoid allocating Java objects.
REGRESSION:
Comments
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6af8f3562069
20-09-2012
EVALUATION String allocation while holding the Threads_lock means we deadlock if a GC happens at that point.
04-09-2012