On Thu, 21 Jul 2022 15:31:48 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
>>> > The following RN is related to this question: >>> > https://bugs.openjdk.org/browse/JDK-8256558 >>> > It explicitly says: `SetNotificationMode can be used to explicitly flush >>> > ObjectFree events, if needed.` >>> >>> 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`. > >> > 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 when 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 monitor on exit. ThreadStart and ThreadDeath events come to mind, since these are now notoriously unpredictable. Thanks, @plummercj @sspitsyn and @coleenp ------------- PR: https://git.openjdk.org/jdk/pull/9168
