On Wed, 22 Jul 2026 20:49:17 GMT, Leonid Mesnik <[email protected]> wrote:
>> 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. > That was my concern above, that we have other cases that could lead to the > same hang. To be clear it is not the same hang - that issue is a self-deadlock. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31982#discussion_r3634770384
