RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v4]
David Holmes
dholmes at openjdk.org
Fri Feb 21 03:19:53 UTC 2025
On Fri, 21 Feb 2025 01:31:42 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 incrementally with one additional commit since the last revision:
>
> review: move suspend point from post_single_step() to get_jvmti_thread_state()
src/hotspot/share/prims/jvmtiExport.cpp line 428:
> 426: // suspend here if there is a suspend request
> 427: ThreadBlockInVM tbivm(thread, true /* allow suspend */);
> 428: }
This positioning seems better than the previous one, but it still causes me concern as a get function should not really have a side-effect of blocking due to suspension, in my view. What does the actual call-stack look like when we get here? We are obviously missing a suspension check for the current thread, but I still feel that should be higher-up the call-stack.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1964731467
More information about the hotspot-runtime-dev
mailing list