On Thu, 27 Mar 2025 01:10:54 GMT, Serguei Spitsyn <sspit...@openjdk.org> wrote:
> This fixes the issue with lack of synchronization between JVMTI thread
> suspend and resume functions in a self-suspend case. More detailed fix
> description is in the first PR comment.
>
> Testing: Ran mach5 tiers 1-6.
The fix contains the following updates:
- Now the internal function `resume_thread()` is executed in a handshake
closure (`JvmtiUnitedHandshakeClosure`). This provides a necessary
synchronization with the `suspend_thread()` in a case of self-suspension. It
would be even better to execute `suspend_thread()` in a handshake closure as
well. But this is harder to make right. It'd still make sense to consider such
an update in the future.
- The `HandshakeState:resume()` is updated to remove the `MutexLocker` and a
duplicated check for `!is_suspended`.
- The `JvmtiVTMSTransition_lock` has been replaced with newly introduced
`JvmtiVThreadSuspend_lock` in the implementation of the `JvmtiVTSuspender`
functions: `register_all_vthreads_suspend()`, `register_all_vthreads_resume()`,
`register_vthread_suspend()`, `register_vthread_resume()`. It is because the
resume operations are executed in handshakes now under protection of the
HanshakeState lock and so, need a higher ranked lock.
- The `JvmtiVTMSTransitionDisabler` has several updates:
- it does nothing (plays a no-op) if the target virtual thread is executed
in a context of current `JavaThread`, so it is trying to disable transitions
for itself
- One entry is removed from the `ProblemList`. It is related to the bug which
is a dup of this one.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24269#issuecomment-2756268404
