JDK-5052099 : ThreadInfo class doesn't contain a method to list all lock monitors
  • Type: Enhancement
  • Component: core-svc
  • Sub-Component: java.lang.management
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2004-05-24
  • Updated: 2005-05-20
  • Resolved: 2005-05-20
Related Reports
Duplicate :  
JDK-6215270 - API to detect all monitors locked/waited-on by any given thread
Description
Name: rmT116609			Date: 05/24/2004


FULL PRODUCT VERSION :
java version "1.5.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta-b32c)
Java HotSpot(TM) Client VM (build 1.5.0-beta-b32c, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
As Bugs 4375402 and 4593133 request there should be methods added to so that developers could provide the same output as Control-Break and Control-/ do today.  In order to do that the code must provide a way to list all the lock monitors a thread holds.  However, ThreadInfo only contains methods getLockName(), getLockOwnerId(), and getLockOwnerName() which appear only to list a single lock monitor.  Threads can hold many lock monitors at once.  Add a method to StackTraceElement  like Object[] getActiveLocks() which represent the lock monitors obtained within this stack frame by the thread.  That would more accurately reflect the output of Control-Break and Control-/.  At least add a method to ThreadInfo like Object[] getLockMonitors() so a user could simply call that method to get all the lock monitors a thread owns.


(Incident Review ID: 270719) 
======================================================================
###@###.### 10/13/04 20:52 GMT
Comments
EVALUATION We'll investigate the needs for getting the list of monitor locks owned by a thread in-process. The current Java Debugging Interface provides the API to get the list of object monitors owned by a given thread (see com.sun.jdi.ThreadReference.ownedMonitors method). The most important usage of monitor information is for deadlock detection. The lock name and its owner info in the ThreadInfo class allows one to detect if a deadlock exists. First, get ThreadInfo for all threads. Then start from a thread that is currently blocked on a monitor lock and then traverse the owner tree to see if there is a cycle. In addition, deadlock can also be detected by calling java.lang.management.ThreadMXBean.findMonitorDeadlockedThreads ###@###.### 2004-05-24 ThreadInfo is designed to cover the thread dump functionality provided by Control-break. Although the hotspot VM implementation of Control-break prints the list of all locked monitors, the requirement for such monitors info is to analyze deadlock. Requirements and use-cases of the list of all lock monitors would help us to consider this in a future release. ###@###.### 10/13/04 20:52 GMT 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. Will investigate for the next release. ###@###.### 2005-1-10 22:43:33 GMT This is a dup of 6215270. ###@###.### 2005-05-20 23:32:47 GMT
10-01-2005