On Wed, 22 Jul 2026 18:52:56 GMT, Patricio Chilano Mateo <[email protected]> wrote:
>>> but my reading of the JVMTI spec is that VMDeath guarantees no new events >>> occur after it, >> >> I did not review JDK-8355631 so I don't know if we considered using an >> atomic flag >> to prevent the posting of further events once we reach VMDeath. We cannot do >> anything reasonable about in-progress callbacks, but we could also check the >> same >> atomic flag in the code that invokes the callbacks to return when the atomic >> flag is >> set... > > Yes, `JvmtiEventController::_execution_finished` was added in 8355631 and is > checked before invoking the callback > [[1]](https://github.com/openjdk/jdk/blob/6e03781ae0d0df17f431f81bb041f34f5b933388/src/hotspot/share/prims/jvmtiExport.cpp#L149). > The issue is that there is always a window in which a thread could read a > false value, and before invoking the callback, the flag could be set by the > terminating thread and the `VMDeath` callback invoked first. I think it comes > down to when an event is considered to have occurred. Is it when executing > the first cpu instruction of the callback function? If the `VMDeath` spec > allowed for in-progress callbacks, including these possible racy events, we > could avoid the wait loop that stalls VM termination. > >> There is another self-hang reported in JDK-8385823 >> > That was my concern above, that we have other cases that could lead to the > same hang. David, thank for care about this! The JVMTI spec indeed say only that events shouldn't be posted after the VMDeath and the primary goal of JDK-8355631 was to implement this. However, if the "in-progress" events cat get unexpected death state that it means that every function in event callback should check for JVMTI_ERROR_WRONG_PHASE. Otherwise agent could crash. So VM now wait for a some time. I didn't thought about such deadlock caused by calling exit from callback. I agree that it would be makes sense to reduce 60 sec timeout. It would be enough to wait for a few seconds. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31982#discussion_r3633701174
