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

David Holmes dholmes at openjdk.org
Fri Feb 14 04:59:11 UTC 2025


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

I can't say that I understand the fix at all. Why would we suspend a platform thread in the middle of `post_single_step`? And what has this to do with the original proposal that only affected virtual threads???

If we don't want a suspended thread to be able to post events we should have probably detected that at a higher-level where it makes sense for the thread to actually suspend.

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

PR Review: https://git.openjdk.org/jdk/pull/23490#pullrequestreview-2616761143


More information about the hotspot-runtime-dev mailing list