Tue, 25 Mar 2014 19:48:50 -0700
8038274: update 8u fix for 8028073 now that 8028280 is backported to 8u
Reviewed-by: coleenp, sspitsyn
src/share/vm/runtime/objectMonitor.cpp | file | annotate | diff | comparison | revisions |
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()) {