On Tue, 21 Jul 2026 23:25:06 GMT, Patricio Chilano Mateo <[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 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? Thanks for looking at this Patricio. The issues you raise were discussed a lot when JDK-8355631 was being fixed (initially it only dealt with the late phase change problem). The problem, as I understand it, is that in-progress callbacks can generate further events which are then happening after vm_death - contrary to spec. But without full synchronization it is inherently racy and you can't get 100% compliance. The current polling loop for 60s is a compromise, but we/I overlooked the interaction with safepoints. It is very easy to get into a temporary "deadlock" with safepoints, hence the simple point fix here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31982#discussion_r3626841757
