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 This pull request has now been integrated. Changeset: f0da04a4 Author: Serguei Spitsyn <[email protected]> URL: https://git.openjdk.org/jdk/commit/f0da04a40a010ed7e561735f0b1fdbd3f02ca42b Stats: 10 lines in 2 files changed: 8 ins; 0 del; 2 mod 8375457: Test serviceability/jvmti/vthread/SelfSuspendDisablerTest/SelfSuspendDisablerTest.java#default timed out Reviewed-by: pchilanomate, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/29802
