On Sat, 21 Feb 2026 08:14:47 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 > > Serguei Spitsyn has updated the pull request incrementally with one > additional commit since the last revision: > > review: replace one check with an assert Thank you for review, Patricio and Alex! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29802#issuecomment-3947245323
