RFR: 8375457: Test serviceability/jvmti/vthread/SelfSuspendDisablerTest/SelfSuspendDisablerTest.java#default timed out

[Patricio Chilano Mateo]

On Wed, 18 Feb 2026 20:41:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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