On Wed, 18 Feb 2026 20:41:54 GMT, Serguei Spitsyn <[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
Looks good to me.
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`?
-------------
Marked as reviewed by pchilanomate (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/29802#pullrequestreview-3833010400
PR Review Comment: https://git.openjdk.org/jdk/pull/29802#discussion_r2834074580
