On Wed, 22 Jul 2026 15:00:06 GMT, Daniel D. Daugherty <[email protected]> wrote:
>> There is another self-hang reported in >> [JDK-8385823](https://bugs.openjdk.org/browse/JDK-8385823) > >> 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31982#discussion_r3632958795
