RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v2]

[Patricio Chilano Mateo]

On Thu, 13 Feb 2025 17:37:27 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVMTI functions `SuspendThread()`, `SuspendThreadList()` and `SuspendAllVirtualThreads()` use the runtime `HandshakeState::suspend()` function `SuspendThreadHandshake` class to suspend the `JavaThread` of a mounted virtual thread. They work under protection of the `JvmtiVTMSTransitionDisabler` to make the association of virtual thread with `JavaThread` stable. The function `HandshakeState::suspend()` creates an instance of`SuspendThreadHandshake`, executes it synchronously and then just returns. The `SuspendThreadHandshake:: do_thread()` in its order create an instance of the `ThreadSelfSuspensionHandshake` (which is a subclass of the `AsyncHandshakeClosure`) to force the handshakee's self-suspension asynchronously. The `HandshakeState::suspend()` does not wait for target thread real self-suspension, nor reaching a safe thread state that can be treated as a suspend-equivalent. This creates problems as the target virtual thread's activity can be observable after the JVMTI `Susp
 endThread()` and others are returned. For instance, some `SingleStep` events can be posted.
>> The fix is to wait in the `HandshakeState::suspend()` for the target handshakee to reach a safe thread state. This is done for the virtual thread case only. The suspension of normal platform threads remains the same.
>> 
>> Testing:
>>  - Ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - removed obsolete fragment that was not removed in last update
>  - review: re-fixed the issue as initial fix was wrong

Right, this is the fix I was thinking about initially. We can always create a test where a suspended target posts an event though, because the target can be seen as handshake-safe after switching to native in `JvmtiJavaThreadEventTransition`. So this fix would prevent posting events enabled after suspension (like this test is doing) but not before. This latter case would not be easy to fix since a callback is executed in native and we allow suspending in such state. Now, I thought suspend only implied the target cannot execute new Java bytecodes (can’t find the precise definition in the JVMTI specs). If that’s the case, why is this a bug in the VM and not a test issue? Or is this a case of still following the specs but trying to do the saner thing?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23490#issuecomment-2657881427