RFR: 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest timed out

[Serguei Spitsyn]

On Thu, 27 Mar 2025 01:10:54 GMT, Serguei Spitsyn <sspitsyn at 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