JDK-8033399 : add a separate ParkEvent for JVM/TI RawMonitor use
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 8
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2014-01-31
  • Updated: 2020-01-29
  • Resolved: 2020-01-29
Related Reports
Relates :  
JDK-8028073 - race condition in ObjectMonitor implementation causing deadlocks
Description
During investigation and work on the following bug:

JDK-8028073 race condition in ObjectMonitor implementation causing deadlocks

the topic of using a separate ParkEvent for JVM/TI RawMonitor
use was brought up.

Here are some comments from JDK-8028073:

David Holmes added a comment - 2014-01-27 18:34
Could there be multiple places in event handling code that could in theory consume unparks and so require the re-issue of an unpark() from different locations in the code?

Seems to me that perhaps raw monitors - given they can be entered from within the normal monitor code - should have their own _event object per thread, so that this accidental consumption of unparks can not occur. 


Daniel Daugherty added a comment - 2014-01-28 12:05 - edited
Re: adding another event object

I think there are some big assumptions in the system that a thread only has
one event structure associated with it. It would be very risky to evolve away
from that assumption

 David Holmes added a comment - 2014-01-29 00:46
Re: adding another event object

As Dave Dice stated in other email there are not big assumptions of there only being one event per thread as there are three distinct events currently used for three different APIs (sleep, object monitors, j.u.c park/unpark). As RawMonitors are a fourth API they really deserve a distinct event too.
Comments
This scenario is hard to reproduce.
29-01-2020
This is a hypothetical scenario from Dan (posted in the RFR thread for 8231289): --------------------------------------------- The scenario that comes to mind: - T1 is contending on an ObjectMonitor and has set waitingToLockMonitor. - T1 calls the jvmtiEventMonitorContendedEnter event handler that contends on a JvmtiRawMonitor and has set waitingToLockRawMonitor. - T1 blocks on the JvmtiRawMonitor and parks. - T2 is exiting the ObjectMonitor and has picked T1 as the successor so it unparks T1. Only T1 is parked for the JvmtiRawMonitor and not for the ObjectMonitor. T2 hasn't quite finished exiting the ObjectMonitor yet... (not sure if this lag is possible) - T1 has unparked early for the JvmtiRawMonitor and at the same time T3 is exiting the JvmtiRawMonitor. - T1 quickly enters the JvmtiRawMonitor and T3 doesn't have to pick a successor so it doesn't do an unpark. - T1 finishes the work of the jvmtiEventMonitorContendedEnter and returns to the caller which is the code that's about to block on the ObjectMonitor... - T1 blocks on the ObjectMonitor and parks. - T2 finishes exiting the ObjectMonitor... Does T1 get unparked? I can't remember when T2 does the unpark() relative to dropping ownership of the ObjectMonitor. If the unpark() is first or if the _owner field setting to NULL lingers... it's possible for T1 to block and park... with nothing to unpark T1... Pure, crazy theory here... ----------------------------------------- But David explained in the review thread for 8231289 why this scenario can't really happen.
07-10-2019
Having been working in the ObjectMonitor code recently in regards to using Java object monitors, and also having tried to reimplement JvmtiRawMonitors, I don't think there is a need for a distinct event. You cannot be queued on a raw monitor and an ObjectMonitor at the same time; and an unpark will only be used for the ParkEvent when you are found to be queued somewhere. There may be cases where spurious wakeups are possible if we unpark at the same time as a timeout, or where we specifically issue extra unparks "just in case", but I cannot see any scenario where an unpark intended for one usage could possibly be consumed by another leading to a stranded thread.
21-09-2019
Better approach may be to redefine JvmtiRawMonitors as basic VM Monitors or PlatformMonitors and do away with the connection to ObjectMonitors and ParkEvents altogether.
27-03-2019
Should be looked at in 11 if we are going to allocate resources for more "monitors" work; definitely don't need this for 10.
05-04-2017
Meant to drop this into hotspot/jvmti.
03-02-2014