JDK-6639341 : sometimes contended-exit event comes after contended-entered on another thread
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2007-12-08
  • Updated: 2012-10-08
  • Resolved: 2009-01-30
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 JDK 7 Other
6u14Fixed 7Fixed hs14Fixed
With help of the D-Light tool I can see that the contended-exit events
comes after contended-entered event on another thread.
This is an example:
  t12:Enter, t14:Enter, t2:Exit, t14:Entered, (t14:Exit is missed), t12:Entered

The tool does not show the t14:Exit event as it is already out of scope.

It happens because the Hotspot monitor-contended-exit probe is located incorrectly.
I think that posting the contended__exit monitor probe needs to be done
before wakee is unparked:

void ObjectMonitor::ExitEpilog (Thread * Self, ObjectWaiter * Wakee) {
   Trigger->unpark() ;

   // Maintain stats and report events to JVMTI
   if (ObjectSynchronizer::_sync_Parks != NULL) {
      ObjectSynchronizer::_sync_Parks->inc() ;
   DTRACE_MONITOR_PROBE(contended__exit, this, object(), Self);

EVALUATION Change was made, but it will not fix situation in ANY case. This change decrease the likelihood that DLight will see out of order contended_exit/contended_enters, but could not eliminate it completely. the contended_enter thread can - recheck the lock on the way to parking - be woken up due to EINTR, spurious wakeups or timers - in any of these cases (not terribly frequent) the requesting thread can actually acquire the lock before the unpark is even called.

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/a7fac4381b50