-
Bug
-
Resolution: Fixed
-
P2
-
6u33
-
b03
-
generic
-
generic
-
Not verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8000377 | 8 | Kevin Walls | P2 | Closed | Fixed | b59 |
JDK-8017852 | 7u45 | Kevin Walls | P2 | Closed | Fixed | b01 |
JDK-8005479 | 7u40 | Kevin Walls | P2 | Resolved | Fixed | b07 |
JDK-2229396 | 6u38 | Kevin Walls | P3 | Closed | Fixed | b01 |
JDK-8005168 | hs24 | Kevin Walls | P2 | Resolved | Fixed | b28 |
JDK-2230552 | hs20.13 | Kevin Walls | P3 | Resolved | Fixed | b01 |
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:
- backported by
-
JDK-8005168 Possible JVM deadlock in ThreadTimesClosure when using HotspotInternal non-public API.
- Resolved
-
JDK-8005479 Possible JVM deadlock in ThreadTimesClosure when using HotspotInternal non-public API.
- Resolved
-
JDK-2230552 Possible JVM deadlock in ThreadTimesClosure when using HotspotInternal non-public API.
- Resolved
-
JDK-8000377 Possible JVM deadlock in ThreadTimesClosure when using HotspotInternal non-public API.
- Closed
-
JDK-8017852 Possible JVM deadlock in ThreadTimesClosure when using HotspotInternal non-public API.
- Closed
-
JDK-2229396 Possible JVM deadlock in ThreadTimesClosure when using HotspotInternal non-public API.
- Closed
- duplicates
-
JDK-6977180 fatal error: acquiring lock Heap_lock/17 out of order with lock Threads_lock/15, mutex.cpp:1293
- Closed
- relates to
-
JDK-8266337 ThreadTimesClosure doesn't handle exceptions properly
- Resolved