On Fri, 20 Feb 2026 16:38:25 GMT, Patricio Chilano Mateo
<[email protected]> wrote:
>> This issue is very intermittent and can be reproduced only with some
>> delaying tweaks. It is not reproducible anymore with the fix.
>> Only JVMTI `SuspendAllVirtualThreads` has this problem. Under protection of
>> an exclusive `MountUnmountDisabler` object, the function registers all
>> virtual threads (except those in the except list) as suspended. Then it does
>> the current thread self-suspension with the `JvmtiEnvBase::suspend_thread()`
>> out of the disabler object context. There can be a race with a concurrently
>> executed JVMTI `ResumeThread` which can notice the thread as suspended, and
>> so, resume it before it managed to suspend itself. This race is kind of
>> artificial but implemented in some testing scenarios, e.g.
>> in`SelfSuspendDisablerTest`.
>> The fix is to avoid registering current thread as suspended, and instead, do
>> it in the `JvmtiEnvBase::suspend_thread()` call. In such a case this
>> function needs to be called with `true` passed as the 3-rd argument. Then
>> the current thread self suspension will behave same way as the current
>> thread would call JVMTI `SuspendThread` to self suspend.
>>
>> Testing:
>> - Mach5 tiers 1-6 are green
>
> src/hotspot/share/prims/jvmtiEnv.cpp line 1083:
>
>> 1081: // It must be suspended in the suspend_thread call out of disabler
>> context.
>> 1082: oop cur_oop = self_tobj();
>> 1083: if (cur_oop != nullptr &&
>> JvmtiVTSuspender::is_vthread_suspended(cur_oop)) {
>
> Shouldn't `JvmtiVTSuspender::is_vthread_suspended(cur_oop)` always be true?
> Also (preexistent) above when we iterate `elist`?
Thank you for checking. Current virtual thread can be in the `except_list`.
Then it has already been resumed at the line 1077.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29802#discussion_r2835074192
