JDK-6215270 : API to detect all monitors locked/waited-on by any given thread
  • Type: Enhancement
  • Component: core-svc
  • Sub-Component: java.lang.management
  • Affected Version: 1.4.2,5.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-01-07
  • Updated: 2010-04-02
  • Resolved: 2005-06-14
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
6 b39Fixed
Related Reports
Duplicate :  
JDK-5081501 - Need API to find out which thread has a specific monitor locked
Duplicate :  
JDK-5052099 - ThreadInfo class doesn't contain a method to list all lock monitors
Relates :  
JDK-5086470 - Add support for java.util.concurrent locks in the lock related facility
Description
A DESCRIPTION OF THE REQUEST :
Issue #4593133 is supposed to include this RFE and it was recently closed as fixed, however it was *not* completely fixed. The entire point of programmatically getting thread-dumps is so we can detect deadlocks, yet the RFE was fixed without providing this functionality. So I will ask explicitly:

We require an API such that the thread-dump API provides us a way to get the list of all monitors locked by a given thread and/or the monitors it is waiting on. The point here is that until we can programmatically reproduce the exact same thread-dump output as produced by the JVM when we hit CTRL-C, this issue won't be closed.

JUSTIFICATION :
Need to be able to programmatically manipulate thread-dump output. Among other things, I personally need it to produce and manipulate thread-dumps in remote process-spaces.
###@###.### 2005-1-07 21:13:32 GMT
Comments
EVALUATION The 5.0 java.lang.management API provides the deadlock detection support. See ThreadMXBean.findMonitorDeadlockedThreads() and ThreadInfo class. You can find out which monitor a thread is blocked to enter or waiting on. Regarding the request for getting all monitors locked by a given thread, the current Java Debugging Interface (JDI) provides the API to get the list of object monitors owned by a given thread (see com.sun.jdi.ThreadReference.ownedMonitors method). However, this information is not necessary for detecting deadlocks. One information that control-break output provides but missing in ThreadInfo is where (which stack frame) a monitor is locked which will help debugging when deadlock is detected. The JDI interface doesn't provide such information either. I consider this as a duplicate of 5052099 and will close it as a dup. ###@###.### 2005-1-10 22:45:40 GMT Providing information about the stack frame that an object monitor was locked is very useful for troubleshooting. We will add a few APIs in java.lang.management in Mustang so that you can find the list of all object monitors currently locked by individual threads. You can find out which stack frame locked each object monitor. See java.lang.management.ThreadMXBean.getAllLockedMonitors and the new MonitorInfo class. This change will be available in B39 Mustang Snapshot Release. See also 5086470 for the monitoring support of java.util.concurrent locks. ###@###.### 2005-05-20 23:07:15 GMT
10-01-2005