RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v4]
Patricio Chilano Mateo
pchilanomate at openjdk.org
Tue Mar 4 20:56:57 UTC 2025
On Tue, 4 Mar 2025 01:37:57 GMT, David Holmes <dholmes at openjdk.org> wrote:
>>> Do we still have a "suspension disabler" that would prevent the suspend from being processed by the mutex blocking?
>>>
>> We have `JavaThread::_is_disable_suspend` for JVMTI, but that only makes the target ignore the `ThreadSelfSuspensionHandshake` (second part of the suspend mechanism), it doesn't prevent the `SuspendThreadHandshake` (first part) from being executed. The suspender considers the target as suspended after the first handshake is done. (Seems this `_is_disable_suspend` should have prevented the first part instead but I'm guessing it wasn't as straightforward without introducing deadlocks). But also note we have the same issue for other events so we need a general solution.
>
> Let me see if I have the sequence of events correct:
> - we have a thread leaving Java to enter the VM, in this case to post a single-step event, which is not suspended
> - when trying to acquire the JvmtiThreadState_lock the thread blocks and becomes handshake/safepoint-safe and is then suspended
> - the thread acquires the lock and goes to post the event but because it has now been suspended it is an error to do so
>
> So what we need is a way to disable suspension so that the transient/temporary switch to _thread_blocked does not allow a suspend request to be processed. I think that is preferable to trying to find where to add a place to check for suspension and actually suspend it.
>
> But how is any of this new?
Yes, that's exactly what's happening. I think the issue with blocking suspend requests while being _thread_blocked is that we might create deadlocks.
> But how is any of this new?
>
We probably never checked for this scenario until this test was added in JDK-8284161. Since that moment we started checking the single step case. Looking at the code history, method `JvmtiExport::get_jvmti_thread_state()` (that leads to the blocked state) was only added later in JDK-8312174, on September 11, 2023. The first reported failure was September 17, 2023.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1980213926
More information about the hotspot-runtime-dev
mailing list