On Wed, 22 Jul 2026 01:47:03 GMT, David Holmes <[email protected]> wrote:
>> 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.
There is another self-hang reported in
[JDK-8385823](https://bugs.openjdk.org/browse/JDK-8385823)
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/31982#discussion_r3626915102
