On Tue, 21 Jul 2026 06:23:09 GMT, David Holmes <[email protected]> wrote:
> Before posting the VM_DEATH event the JVMTI code spins for up to 60 seconds > to allow in-progress callbacks to complete. If one of those callbacks > requires a safepoint while executing, then it will not be able to attain it > until the 60s spin is over - thus causing an apparent "hang" at VM > termination. The simple fix is to insert a `ThreadBlockInVM` in the loop so > that safepoint requests are honored. > > Testing: > - tiers 1-5 > - new regression test > > Thanks. > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). src/hotspot/share/prims/jvmtiEventController.cpp line 1249: > 1247: // will immediately see `execution_finished()` and return (dropping > the count). > 1248: while (in_callback_count() > 0) { > 1249: // Ensure we are safepoint-safe else we may deadlock with active > callbacks. Maybe s/deadlock with/delay? src/hotspot/share/prims/jvmtiEventController.cpp line 1250: > 1248: while (in_callback_count() > 0) { > 1249: // Ensure we are safepoint-safe else we may deadlock with active > callbacks. > 1250: ThreadBlockInVM tbivm(JavaThread::current()); So even if we honor safepoints here, a thread running or blocked for a long time in a JVMTI callback could delay VM termination for up to 60s. Do we really need to wait for all current callbacks to return before posting `VMDeath`? I see this behavior was added not that long ago in 8355631, but my reading of the JVMTI spec is that `VMDeath` guarantees no new events occur after it, not that callbacks from events posted before it have already returned. I understand there is always a race with other threads concurrently posting events after `JvmtiEventController::is_execution_finished()` is set to true, but maybe this could be clarified in the specs? Also, even now we are not really waiting until all callbacks are done, so maybe we could also tune down the max wait time to minimize the stall time? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31982#discussion_r3626366128 PR Review Comment: https://git.openjdk.org/jdk/pull/31982#discussion_r3626364801
