JDK-6611348 : missed JVMTI monitor events in wait-morphing code
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 7
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2007-09-30
  • Updated: 2023-12-13
  • Resolved: 2016-11-04
Related Reports
Relates :  
JDK-6562569 - REGRESSION: can not see BLOCKED state change after patching 5104215 diff.
Description
Thread waiting on the monitor usually can't uncontentiously reenter the monitor
after it gets notified because the monitor is still held by the notifying thread.
The reworked wait-morphing synchronization code in notify/notifyAll does not unpark
waiting thread anymore but simply shifts it from the Wait queue to the Entry queue.
In such a case, waiting thread itself can't report JVMTI monitor "waited" and
"contended_enter" events. So that, the "contended_enter" event is missed and the
"waited" event is reported after thread is woken up.
Current behavior is incorrect and must be fixed.
Comments
This is not on our list of current priorities. If this changes, please reopen this issue.
04-11-2016
I think the best fix here is to revise the spec to allow for these events to be omitted. Otherwise we cripple performance for the sake of someone maybe wanting an event.
11-08-2013
According to the "JPRT Bug Updates" this issue had to be in the resolved state. But these references belong to the different issue 6562569 . The following was the comment to the 6562569 commit: Fixed 6562569: REGRESSION: can not see BLOCKED state change after patching 5104215 diff. [Dave.Dice, David H., Dan D.] Webrev: http://javaweb.sfbay/~ss45998/webrev/2007/hs_wait.Oct3 Problem: The backport of the wait-morphing code to 5u6 caused this "regression". The thread state remains WAITING when "waiting" JavaThread is moved from "WaitSet" to "Entry" queue by the "notifying" JavaThread. However it must be changed from WAITING to BLOCKED (on monitor re-enter). From 5.0u6 though 6 and 7 the behaviour is now consistent but wrong and so one fix should be driven through for all platforms. Solution: The solution is that the "notifying" JavaThread changes the state of "waiting" JavaThread from WAITING to BLOCKED. It is done in a _WaitSetLock critical section. There are three other things to care about for this special case: 1. Supporting the contention monitoring (in threadService.hpp). The higher-level helper can't be used anymore and so, the lower-level static functions are used: wait_reenter_begin/wait_reenter_end. 2. Posting the JVMTI MONITOR_WAITED and MONITOR_CONTENDED_ENTER events. Current wait-morphing semantics implementation skips these events. 3. Firing the Dtrace usdt probe "contended__enter". The Dtrace usdt probe "waited" has to be in sync with the JVMTI MONITOR_WAITED event. The following separate CR has been created to cover the issues #2 and #3: 6611348 missed JVMTI monitor events in wait-morphing code
09-08-2013
EVALUATION The description is clear about the bug. Let's consider fixing it in the current release: marked BB-current.
30-09-2007