add a separate ParkEvent for JVM/TI RawMonitor use

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.