JDK-6455295 : JVMTI Spec: Clarify the location at which MonitorWait/MonitorWaited events occur
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2006-08-01
  • Updated: 2016-11-04
  • Resolved: 2016-11-04
Related Reports
Relates :  
JDK-6455296 - Clarify the JDWP/JDI specs for the location at which MonitorWait/MonitorWaited events occur
Relates :  
JDK-6455248 - JVMTI Doc: MonitorWait / MonitorWaited event description misleading
Relates :  
JDK-8075259 - JVMTI: Class initialization generates MonitorWaited without matched MonitorWait
Description
The JVMTI spec for MonitorWait says 
  Sent when a thread is about to wait on an object

The javadoc for Object.wait() says:

   This method causes the current thread (call it T) to place itself in the wait
   set for this object and then to relinquish any and all synchronization claims on this     object.

Should the JVMTI spec should be clearer about just what state the thread
is in when the event occurs, relative to the above description?  EG?

- has the thread placed itself in the wait state?
- has the thread relinquished synch claims?

For example, if a ContendedMonitorEntered event is enabled for this monitor,
and will be sent, will it be sent before or after the MonitorWait event?

Ditto the above for MonitorWaited.
Comments
This is not on our list of current priorities. If this changes, please reopen this issue.
04-11-2016
If you do a wait() you must already own the monitor so the ContendedMonitorEntered has already happened. A second one may be generated when the wait is trying to return and must reacquire the monitor. Overspecifying this constrains the implementation too much.
08-08-2013
EVALUATION See also: 6455296. When this bug is fixed, fix that one too. The specs are vague about the locations at which MonitorWait/Waited occur relative to the steps defined in java.lang.Object.wait().
01-08-2006