Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8033399

add a separate ParkEvent for JVM/TI RawMonitor use



    • Enhancement
    • Status: Closed
    • P4
    • Resolution: Won't Fix
    • 8
    • tbd
    • hotspot
    • None
    • generic
    • generic


      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.


        Issue Links



              Unassigned Unassigned
              dcubed Daniel Daugherty
              0 Vote for this issue
              4 Start watching this issue