On Thu, 21 Jul 2022 05:42:49 GMT, Serguei Spitsyn <sspit...@openjdk.org> wrote:
> > That wasn't quite what I was getting at. My comment / question was much > > more general. If you call SetEventNotificationMode() to disable a specific > > event, once it returns are you guaranteed that no more events will be > > delivered. This means that if JVMTI was in the middle of calling the event > > handler at the same time that SetEventNotificationMode() is called, then > > before returning, SetEventNotificationMode() will block until the event > > handler returns. > > There is no such general guarantee with calls to the > `SetEventNotificationMode`. It is not in the `JVM TI` spec. My view is that > it is racy by the `JVM TI` design. I spent some time in the past to fix > several problems related to the `JDWP` agent shutdown as the `WRONG_PHASE` > error code was appearing in the middle of an event handler execution. The > `WRONG_PHASE` problem is similar kind of sync problem. `JVM TI` does not > guarantee that all event callbacks are completed before the `JVM TI `phase is > switched to `JVMTI_PHASE_DEAD`. This becomes a problem with the test tries to free a raw monitor on exit. It first disable events, then it frees the raw monitor that the even handler synchronizes on. However, it's possible that an event can be in flight when doing this (an event that was triggered before disabling events, but not fully delivered yet). So now you have a chicken-and-egg problem because you need a 2nd raw monitor to synchronize around freeing the 1st raw monitor. So the end result is you can't always safely cleanup on test exit the way we currently are. I think we are getting away with it because the set of events we expect is fixed or predictable. So once the test decides it is done, it won't get more events, even if they are not disabled. Thus we can free the raw monitor after disabling events without worry of some spurious event causing an untimely entry into the event handler. However, I thought there was one test you fixed where we had this exact problem, and you fixed it by not freeing the raw m onitor on exit. ThreadStart and ThreadDeath events come to mind, since these are now notoriously unpredictable. ------------- PR: https://git.openjdk.org/jdk/pull/9168
