1.1 --- a/src/share/vm/runtime/objectMonitor.cpp Tue Mar 25 12:43:29 2014 -0700
1.2 +++ b/src/share/vm/runtime/objectMonitor.cpp Tue Mar 25 19:48:50 2014 -0700
1.3 @@ -1600,33 +1600,25 @@
1.4 // post monitor waited event. Note that this is past-tense, we are done waiting.
1.5 if (JvmtiExport::should_post_monitor_waited()) {
1.6 JvmtiExport::post_monitor_waited(jt, this, ret == OS_TIMEOUT);
1.7 - }
1.8
1.9 - // Without the fix for 8028280, it is possible for the above call:
1.10 - //
1.11 - // Thread::SpinAcquire (&_WaitSetLock, "WaitSet - unlink") ;
1.12 - //
1.13 - // to consume the unpark() that was done when the successor was set.
1.14 - // The solution for this very rare possibility is to redo the unpark()
1.15 - // outside of the JvmtiExport::should_post_monitor_waited() check.
1.16 - //
1.17 - if (node._notified != 0 && _succ == Self) {
1.18 - // In this part of the monitor wait-notify-reenter protocol it
1.19 - // is possible (and normal) for another thread to do a fastpath
1.20 - // monitor enter-exit while this thread is still trying to get
1.21 - // to the reenter portion of the protocol.
1.22 - //
1.23 - // The ObjectMonitor was notified and the current thread is
1.24 - // the successor which also means that an unpark() has already
1.25 - // been done. The JVMTI_EVENT_MONITOR_WAITED event handler can
1.26 - // consume the unpark() that was done when the successor was
1.27 - // set because the same ParkEvent is shared between Java
1.28 - // monitors and JVM/TI RawMonitors (for now).
1.29 - //
1.30 - // We redo the unpark() to ensure forward progress, i.e., we
1.31 - // don't want all pending threads hanging (parked) with none
1.32 - // entering the unlocked monitor.
1.33 - node._event->unpark();
1.34 + if (node._notified != 0 && _succ == Self) {
1.35 + // In this part of the monitor wait-notify-reenter protocol it
1.36 + // is possible (and normal) for another thread to do a fastpath
1.37 + // monitor enter-exit while this thread is still trying to get
1.38 + // to the reenter portion of the protocol.
1.39 + //
1.40 + // The ObjectMonitor was notified and the current thread is
1.41 + // the successor which also means that an unpark() has already
1.42 + // been done. The JVMTI_EVENT_MONITOR_WAITED event handler can
1.43 + // consume the unpark() that was done when the successor was
1.44 + // set because the same ParkEvent is shared between Java
1.45 + // monitors and JVM/TI RawMonitors (for now).
1.46 + //
1.47 + // We redo the unpark() to ensure forward progress, i.e., we
1.48 + // don't want all pending threads hanging (parked) with none
1.49 + // entering the unlocked monitor.
1.50 + node._event->unpark();
1.51 + }
1.52 }
1.53
1.54 if (event.should_commit()) {
