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 Thank you for review, Patricio! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29802#issuecomment-3937128225
