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

Serguei Spitsyn sspitsyn at openjdk.org
Wed Apr 9 05:46:32 UTC 2025


On Tue, 8 Apr 2025 22:59:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thanks for the summary Serguei. I would only add that IMO, given that it’s already clear there could be many suspend points before even reaching one of this `JvmtiExport::post_*` methods (like the one shown in #3), I would just address all these cases here too my moving the suspend check outside of the `thread->is_vthread_mounted() && thread->jvmti_thread_state() == nullptr` conditional. But since this PR has already been blocked for too long I’m okay if we only want to address the specific suspend point in #1.
>
> I thought we already guarded/handled suspension whilst acquiring a mutex, as a general case. ??? Now I am getting really confused about the state of the world.

I guess, you've already figured this out even though it pretty confusing.
One more explanation would not hurt.
We may get a new suspend request down the call to `thread_started()=>state_for()` in the `MutexLocker mu(JvmtiThreadState_lock)` but the the suspending is not allowed in this `MutexLocker`. So, we need to add a suspend point after this call:

    JvmtiEventController::thread_started(thread);
+    if (allow_suspend && thread->is_suspended()) {
+      // suspend here if there is a suspend request
+      ThreadBlockInVM tbivm(thread, true /* allow suspend */);
+    }

I'm not sure, if it is possible to allow a suspend in this `MutexLocker`.
It would simplify the code if there is a way to do it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r2034486921


More information about the hotspot-runtime-dev mailing list