JDK-4546581 : GetCurrentContendedMonitor, GetOwnedMonitorInfo, GetMonitorInfo not implemented
  • Type: Bug
  • Component: vm-legacy
  • Sub-Component: jvmdi
  • Affected Version: 1.3.0,1.3.1,1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS:
    generic,solaris_2.6,windows_nt,windows_2000 generic,solaris_2.6,windows_nt,windows_2000
  • CPU: generic,x86,sparc
  • Submitted: 2001-12-04
  • Updated: 2020-06-22
  • Resolved: 2002-11-07
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
1.4.2 mantisFixed
Related Reports
Duplicate :  
JDK-4327280 - some interface functions are not implemented
Relates :  
JDK-4763264 - JDI spec: ObjectReference.waitingThreads: add the owner must be suspended
Relates :  
JDK-8247972 - Specification clarification needed for JVM TI GetObjectMonitorUsage
Description

Name: egR10015			Date: 12/04/2001


The following three JVMDI methods are not implemented:

GetCurrentContendedMonitor
GetOwnedMonitorInfo
GetMonitorInfo

This bug affects the following tests from testbase_nsk:

nsk/jvmdi/GetCurrentContendedMonitor/contmon001
nsk/jvmdi/GetCurrentContendedMonitor/contmon002
nsk/jvmdi/GetOwnedMonitorInfo/ownmoninf001
nsk/jvmdi/GetOwnedMonitorInfo/ownmoninf002

======================================================================

###@###.### 2002-10-25

When I implemented the feature, I found the following additional
tests by grepping for each interface name:

nsk/jdi/VirtualMachine/canGetCurrentContendedMonitor/cangccm001
nsk/jdi/VirtualMachine/canGetMonitorInfo/cangetmonitorinfo001
nsk/jdi/VirtualMachine/canGetOwnedMonitorInfo/cangetinfo001
nsk/jvmdi/GetCurrentContendedMonitor/contmon003
nsk/jvmdi/GetMonitorInfo/getmoninfo001
nsk/jvmdi/GetMonitorInfo/getmoninfo002
nsk/jvmdi/GetMonitorInfo/getmoninfo003
nsk/jvmdi/GetMonitorInfo/getmoninfo004
nsk/jvmdi/GetMonitorInfo/getmoninfo005
nsk/jvmdi/GetOwnedMonitorInfo/ownmoninf003

During my pre-integration NSK run for my 2002.10.24 batch, the following
tests failed:

nsk/jdi/ThreadReference/ownedMonitors/ownedmonitors001
nsk/jdi/ThreadReference/ownedMonitors/ownedmonitors002
nsk/jdwp/ObjectReference/MonitorInfo/monitorinfo001
nsk/jdwp/ThreadReference/CurrentContendedMonitor/curcontmonitor001
nsk/jdwp/ThreadReference/OwnedMonitors/ownmonitors001
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis mantis-b07 VERIFIED IN: mantis
14-06-2004
EVALUATION ###@###.### 2002-10-11 The JVM/DI GetMonitorInfo() API returns a pointer to the following struct: typedef struct { jthread owner; jint entry_count; jint waiter_count; jthread *waiters; } JVMDI_monitor_info; The owner field is pretty obvious, but the other fields are not. The entry_count field could be the number of times the monitor is entered by the owning thread (recursion count) or it could be the number of threads waiting to enter (contention count). The waiter_count field specified the number of jthread pointers in the waiters array. However, is the waiters array the threads waiting to enter the monitor, the threads doing an Object.wait() or both? The resolve this mystery, I'm using the JDI spec for ObjectReference: public int entryCount() Returns the number times this object's monitor has been entered by the current owning thread. public List waitingThreads() Returns a List containing a ThreadReference for each thread currently waiting for this object's monitor. See ThreadReference.currentContendedMonitor() for information about when a thread is considered to be waiting for a monitor. ThreadReference.currentContendedMonitor() says: The thread can be waiting for a monitor through entry into a synchronized method, the synchronized statement, or Object.wait(long). I'm planning to implement the GetMonitorInfo() API to meet the expectations of JDI's use of the interface. ###@###.### 2002-10-14 GetCurrentContendedMonitor() returns a jobject for two conditions: - the specified thread is waiting to enter - the specified thread is waiting to regain through java.lang.Object.wait The first condition is clear. The second needs clarification. An Object.wait() call has two parts: the wait for notification (or timeout) part and the reenter part. I believe the phrase "waiting to regain" is intended to apply to the reenter part. However, the JDI spec needs to be checked to see what is expected by the higher layers. ThreadReference.currentContendedMonitor() says: Returns an ObjectReference for the monitor, if any, for which this thread is currently waiting. The thread can be waiting for a monitor through entry into a synchronized method, the synchronized statement, or Object.wait(long). The status() method can be used to differentiate between the first two cases and the third. ThreadReference.status() says: Returns the thread's status. If the thread is not suspended the thread's current status is returned. If the thread is suspended, the thread's status before the suspension is returned (or THREAD_STATUS_UNKNOWN if this information is not available. isSuspended() can be used to determine if the thread has been suspended. ThreadReference.THREAD_STATUS_WAIT says: Thread is waiting - Thread.wait() or JVM_MonitorWait() was called Looks like the JDI layer is expecting that a call into Object.wait() will result in the thread showing a contended monitor.
11-06-2004
SUGGESTED FIX ###@###.### 2002-10-15 See the attached 4546581-webrev.tar file for the pre-code review version of the changes. ###@###.### 2002-10-18 See the attached 4546581-webrev-cr1.tar file the changes from the code review. ###@###.### 2002-10-28 See the attached 4546581-webrev-cr2.tar file for the changes made after an NSK test cycle. There were also two minor changes to the JPDA backend: ------- src/share/back/ObjectReferenceImpl.c ------- *** /tmp/sccs.MzaGmQ Mon Oct 28 06:24:41 2002 --- ObjectReferenceImpl.c Fri Oct 25 18:01:41 2002 *************** *** 173,179 **** WRITE_GLOBAL_REF(env, out, info.waiters[i]); } ! jdwpFree(info.waiters); return JNI_TRUE; } --- 173,181 ---- WRITE_GLOBAL_REF(env, out, info.waiters[i]); } ! if (info.waiter_count != 0) { ! jdwpFree(info.waiters); ! } return JNI_TRUE; } ------- src/share/back/ThreadReferenceImpl.c ------- *** /tmp/sccs.NzaGmQ Mon Oct 28 06:24:41 2002 --- ThreadReferenceImpl.c Fri Oct 25 16:15:35 2002 *************** *** 312,318 **** WRITE_GLOBAL_REF(env, out, monitor); } ! jdwpFree(info.owned_monitors); return JNI_TRUE; } --- 312,320 ---- WRITE_GLOBAL_REF(env, out, monitor); } ! if (info.owned_monitor_count != 0) { ! jdwpFree(info.owned_monitors); ! } return JNI_TRUE; }
11-06-2004
PUBLIC COMMENTS .
10-06-2004