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

[David Holmes]

On Tue, 4 Mar 2025 20:54:13 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> 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.

I don't think we should block suspend requests in all cases of being `_thread_blocked`, but `get_jvmti_thread_state` is a special case. We either need to have a general suspension suppression mechanism (which I thought already existed - but may it was in old code), or we need to special-case the acquisition of the `Thread_State_lock`.

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

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