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

[Serguei Spitsyn]

On Tue, 8 Apr 2025 03:20:17 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The `get_jvmti_thread_state()` function is called from `JvmtiExport::at_single_stepping_point()`.  It can block for virtual threads. Then the `SingleStep` events can be enabled at that point. The incorrect behavior is that the `SingleStep` events will be posted even though the virtual thread has been suspended with the JVMTI `SuspendThread`, `SuspendThreadList`, or `SuspendAllVirtualThreads`. The fix is to add a suspend point for virtual threads to the `get_jvmti_thread_state()` function.
>> 
>> Testing:
>>  - Ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - Merge
>  - review: add workaround for post_dynamic_code_generated_while_holding_locks
>  - Merge
>  - Merge
>  - review: move suspend point from post_single_step() to get_jvmti_thread_state()
>  - Merge
>  - removed obsolete fragment that was not removed in last update
>  - review: re-fixed the issue as initial fix was wrong
>  - 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected

> Okay as a point fix what has been proposed seems reasonable. I would like some additional comments please.

Thank you for looking at it again and your passion, David.

> But I would really like to see some high-level design documents for all the interactions here because I can't get complete sense of the big picture here. It seems we are forever playing whack-a-mole when it comes to virtual threads and JVMTI.

What kind of a design document can it be? The complexity comes from the fact that virtual threads can be unmounted so we can't walk all of them when JVMTI `SetEventNotificationMode()` is called to create a `JvmtiThreadState` object for each unmounted virtual thread. Another complexity comes from the scalability requirements. The last point where we still can create a `JvmtiThreadState` object is before an event posting. So, it is done with a call to the  `jvmtiEventController::thread_started()`.

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

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