Mercurial > hg > truffle

comparison src/share/vm/runtime/objectMonitor.cpp @ 17787:8c6165f9ea8e

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
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 d35df3079834
children a7d4d4655766
comparison
equal deleted inserted replaced
17786:eb6b3ac64f0e 17787:8c6165f9ea8e
1598 // (Don't cache naked oops over safepoints, of course). 1598 // (Don't cache naked oops over safepoints, of course).
1599 1599
1600 // post monitor waited event. Note that this is past-tense, we are done waiting. 1600 // post monitor waited event. Note that this is past-tense, we are done waiting.
1601 if (JvmtiExport::should_post_monitor_waited()) { 1601 if (JvmtiExport::should_post_monitor_waited()) {
1602 JvmtiExport::post_monitor_waited(jt, this, ret == OS_TIMEOUT); 1602 JvmtiExport::post_monitor_waited(jt, this, ret == OS_TIMEOUT);
1603 } 1603
1604 1604 if (node._notified != 0 && _succ == Self) {
1605 // Without the fix for 8028280, it is possible for the above call: 1605 // In this part of the monitor wait-notify-reenter protocol it
1606 // 1606 // is possible (and normal) for another thread to do a fastpath
1607 // Thread::SpinAcquire (&_WaitSetLock, "WaitSet - unlink") ; 1607 // monitor enter-exit while this thread is still trying to get
1608 // 1608 // to the reenter portion of the protocol.
1609 // to consume the unpark() that was done when the successor was set. 1609 //
1610 // The solution for this very rare possibility is to redo the unpark() 1610 // The ObjectMonitor was notified and the current thread is
1611 // outside of the JvmtiExport::should_post_monitor_waited() check. 1611 // the successor which also means that an unpark() has already
1612 // 1612 // been done. The JVMTI_EVENT_MONITOR_WAITED event handler can
1613 if (node._notified != 0 && _succ == Self) { 1613 // consume the unpark() that was done when the successor was
1614 // In this part of the monitor wait-notify-reenter protocol it 1614 // set because the same ParkEvent is shared between Java
1615 // is possible (and normal) for another thread to do a fastpath 1615 // monitors and JVM/TI RawMonitors (for now).
1616 // monitor enter-exit while this thread is still trying to get 1616 //
1617 // to the reenter portion of the protocol. 1617 // We redo the unpark() to ensure forward progress, i.e., we
1618 // 1618 // don't want all pending threads hanging (parked) with none
1619 // The ObjectMonitor was notified and the current thread is 1619 // entering the unlocked monitor.
1620 // the successor which also means that an unpark() has already 1620 node._event->unpark();
1621 // been done. The JVMTI_EVENT_MONITOR_WAITED event handler can 1621 }
1622 // consume the unpark() that was done when the successor was
1623 // set because the same ParkEvent is shared between Java
1624 // monitors and JVM/TI RawMonitors (for now).
1625 //
1626 // We redo the unpark() to ensure forward progress, i.e., we
1627 // don't want all pending threads hanging (parked) with none
1628 // entering the unlocked monitor.
1629 node._event->unpark();
1630 } 1622 }
1631 1623
1632 if (event.should_commit()) { 1624 if (event.should_commit()) {
1633 post_monitor_wait_event(&event, node._notifier_tid, millis, ret == OS_TIMEOUT); 1625 post_monitor_wait_event(&event, node._notifier_tid, millis, ret == OS_TIMEOUT);
1634 } 1626 }