# HG changeset patch
# User dcubed
# Date 1395802130 25200
# Node ID 8c6165f9ea8efb1f50eae0030162d9bc873ee7f3
# Parent  eb6b3ac64f0eb6c182e41b8051e5eb0ec347e284
8038274: update 8u fix for 8028073 now that 8028280 is backported to 8u
Reviewed-by: coleenp, sspitsyn

diff -r eb6b3ac64f0e -r 8c6165f9ea8e src/share/vm/runtime/objectMonitor.cpp
--- a/src/share/vm/runtime/objectMonitor.cpp	Tue Mar 25 12:43:29 2014 -0700
+++ b/src/share/vm/runtime/objectMonitor.cpp	Tue Mar 25 19:48:50 2014 -0700
@@ -1600,33 +1600,25 @@
      // post monitor waited event. Note that this is past-tense, we are done waiting.
      if (JvmtiExport::should_post_monitor_waited()) {
        JvmtiExport::post_monitor_waited(jt, this, ret == OS_TIMEOUT);
-     }
 
-     // Without the fix for 8028280, it is possible for the above call:
-     //
-     //   Thread::SpinAcquire (&_WaitSetLock, "WaitSet - unlink") ;
-     //
-     // to consume the unpark() that was done when the successor was set.
-     // The solution for this very rare possibility is to redo the unpark()
-     // outside of the JvmtiExport::should_post_monitor_waited() check.
-     //
-     if (node._notified != 0 && _succ == Self) {
-       // In this part of the monitor wait-notify-reenter protocol it
-       // is possible (and normal) for another thread to do a fastpath
-       // monitor enter-exit while this thread is still trying to get
-       // to the reenter portion of the protocol.
-       //
-       // The ObjectMonitor was notified and the current thread is
-       // the successor which also means that an unpark() has already
-       // been done. The JVMTI_EVENT_MONITOR_WAITED event handler can
-       // consume the unpark() that was done when the successor was
-       // set because the same ParkEvent is shared between Java
-       // monitors and JVM/TI RawMonitors (for now).
-       //
-       // We redo the unpark() to ensure forward progress, i.e., we
-       // don't want all pending threads hanging (parked) with none
-       // entering the unlocked monitor.
-       node._event->unpark();
+       if (node._notified != 0 && _succ == Self) {
+         // In this part of the monitor wait-notify-reenter protocol it
+         // is possible (and normal) for another thread to do a fastpath
+         // monitor enter-exit while this thread is still trying to get
+         // to the reenter portion of the protocol.
+         //
+         // The ObjectMonitor was notified and the current thread is
+         // the successor which also means that an unpark() has already
+         // been done. The JVMTI_EVENT_MONITOR_WAITED event handler can
+         // consume the unpark() that was done when the successor was
+         // set because the same ParkEvent is shared between Java
+         // monitors and JVM/TI RawMonitors (for now).
+         //
+         // We redo the unpark() to ensure forward progress, i.e., we
+         // don't want all pending threads hanging (parked) with none
+         // entering the unlocked monitor.
+         node._event->unpark();
+       }
      }
 
      if (event.should_commit()) {