Mercurial > hg > truffle
changeset 17787:8c6165f9ea8e
8038274: update 8u fix for 8028073 now that 8028280 is backported to 8u
Reviewed-by: coleenp, sspitsyn
| author | dcubed |
|---|---|
| date | Tue, 25 Mar 2014 19:48:50 -0700 |
| parents | eb6b3ac64f0e |
| children | f2294a37e723 |
| files | src/share/vm/runtime/objectMonitor.cpp |
| diffstat | 1 files changed, 18 insertions(+), 26 deletions(-) [+] |
line wrap: on
line diff
--- 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()) {