-
Bug
-
Resolution: Won't Fix
-
P4
-
1.4.2, 5.0
-
generic, sparc
-
generic, solaris_9
###@###.### 2002-10-15
While working on the fix for the following bug:
4546581 4/5 GetCurrentContendedMonitor, GetOwnedMonitorInfo,
GetMonitorInfo not implemented
I ran into a minor bug in the following test:
nsk/jdi/VirtualMachine/canGetMonitorInfo/cangetmonitorinfo001
The main thread in the debuggee starts a worker thread while holding
a monitor, lockingObject. The worker thread blocks on the monitor
and the debuggee main thread waits for the debugger to tell it to
proceed.
The debugger suspends the worker thread while it is waiting to enter
the monitor and verifies the JVM/DI GetCurrentContendedMonitor()
call. It also verifies the JVM/DI GetMonitorInfo() call indirectly
via the JDI ObjectReference.waitingThreads() call.
The GetMonitorInfo() call fails because the debuggee main thread is
not suspended (JVMDI_ERROR_THREAD_NOT_SUSPENDED). Here is the
relevant requirements from the JVM/DI spec:
Get Monitor Info
:
Get information about the the object's monitor The fields of the
JVMDI_owned_monitor_info structure are filled in with details of
the monitor. Each thread that might affect the monitor state must
either be suspended or must be the current thread.
The debuggee main thread owns the monitor and is not the caller of
GetMonitorInfo() so it must be suspended.
The JDI spec for ObjectReference.waitingThreads() does not document
the requirement that the owner of the monitor needs to be suspended
(or the current thread). This is because there is no 1-1 mapping
between the JDI APIs and the JVM/DI APIs. The waitingThreads() API
doesn't care about the owning thread. In other words, the
waitingThreads() API doesn't know that it is built on top of the
JVM/DI GetMonitorInfo() API so it doesn't describe requirements
for the underlying API that do not directly map to the information
that it is trying to return (a list of waiting threads).
It is entirely possible that the ObjectReference.waitingThreads()
API should be suspending the thread that owns the object on behalf
of the caller. However, I can't make that call.
While working on the fix for the following bug:
4546581 4/5 GetCurrentContendedMonitor, GetOwnedMonitorInfo,
GetMonitorInfo not implemented
I ran into a minor bug in the following test:
nsk/jdi/VirtualMachine/canGetMonitorInfo/cangetmonitorinfo001
The main thread in the debuggee starts a worker thread while holding
a monitor, lockingObject. The worker thread blocks on the monitor
and the debuggee main thread waits for the debugger to tell it to
proceed.
The debugger suspends the worker thread while it is waiting to enter
the monitor and verifies the JVM/DI GetCurrentContendedMonitor()
call. It also verifies the JVM/DI GetMonitorInfo() call indirectly
via the JDI ObjectReference.waitingThreads() call.
The GetMonitorInfo() call fails because the debuggee main thread is
not suspended (JVMDI_ERROR_THREAD_NOT_SUSPENDED). Here is the
relevant requirements from the JVM/DI spec:
Get Monitor Info
:
Get information about the the object's monitor The fields of the
JVMDI_owned_monitor_info structure are filled in with details of
the monitor. Each thread that might affect the monitor state must
either be suspended or must be the current thread.
The debuggee main thread owns the monitor and is not the caller of
GetMonitorInfo() so it must be suspended.
The JDI spec for ObjectReference.waitingThreads() does not document
the requirement that the owner of the monitor needs to be suspended
(or the current thread). This is because there is no 1-1 mapping
between the JDI APIs and the JVM/DI APIs. The waitingThreads() API
doesn't care about the owning thread. In other words, the
waitingThreads() API doesn't know that it is built on top of the
JVM/DI GetMonitorInfo() API so it doesn't describe requirements
for the underlying API that do not directly map to the information
that it is trying to return (a list of waiting threads).
It is entirely possible that the ObjectReference.waitingThreads()
API should be suspending the thread that owns the object on behalf
of the caller. However, I can't make that call.
- relates to
-
JDK-4546581 GetCurrentContendedMonitor, GetOwnedMonitorInfo, GetMonitorInfo not implemented
-
- Closed
-