• Type: Bug
• Component: hotspot
• Sub-Component: runtime
• Affected Version: 8u20

• Priority: P4
• Status: Closed
• Resolution: Fixed
• OS: generic
• CPU: generic

• Submitted: 2014-03-24
• Updated: 2015-02-10
• Resolved: 2014-03-26

JDK 7	JDK 8
7u80Fixed	8u20 b08Fixed

Here's the remaining diffs between the 8u-hs-dev and JDK9-hs versions of the file: $ diff src/share/vm/runtime/objectMonitor.cpp{,.jdk9-hs} 237c237 < // dequeue operation after acquisition (in the ::enter() epilog) and --- > // dequeue operation after acquisition (in the ::enter() epilogue) and 692c692 < // ST Responsible=null; MEMBAR (in enter epilog - here) --- > // ST Responsible=null; MEMBAR (in enter epilogue - here) 2058c2058 < // Slighty racy, but benign ... --- > // Slightly racy, but benign ... 24-03-2014 Here's the 'diff -w' which doesn't show all the noise of the two space indent change: $ diff -w src/share/vm/runtime/objectMonitor.cpp{.orig,}1603d1602 < } 1605,1612d1603 < // 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. < // 1630a1622 > } 24-03-2014 Here's the 'hg diff': $ hg diff diff -r a007d73f3fdc src/share/vm/runtime/objectMonitor.cpp --- a/src/share/vm/runtime/objectMonitor.cpp Mon Mar 24 14:20:49 2014 -0700 +++ b/src/share/vm/runtime/objectMonitor.cpp Mon Mar 24 15:46:00 2014 -0700 @@ -1600,33 +1600,25 @@ void ObjectMonitor::wait(jlong millis, b // 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()) { 24-03-2014