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

[Patricio Chilano Mateo]

On Mon, 24 Feb 2025 02:13:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Or should we simply be passing `allow_suspend=true` into more `ThreadBlockInVM` transitions?
>
> And again what is the call stack for this?

> But I would expect many blocked transitions to relate to something that will causes events to be posted, so do we end up effectively doing the suspension check when coming out of the blocked state?
>
Only for the ones in ObjectMonitor, JvmtiRawMonitor and JavaThread::wait_for_object_deoptimization(). In these cases we know there are no VM monitors held though.

> Or should we simply be passing allow_suspend=true into more ThreadBlockInVM transitions?
>
I think this would be harder to get right. First because these ThreadBlockInVM could be anywhere along the path where we post an event. But also because at those points the thread could be holding VM monitors so we cannot suspend. Here where we post the event we are already checking no VM monitors are held.

> And again what is the call stack for this?
>
For single step event the call is coming from InterpreterRuntime::at_safepoint():


Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x1212523]  JvmtiExport::get_jvmti_thread_state(JavaThread*)+0xd3  (jvmtiExport.cpp:425)
V  [libjvm.so+0x121de66]  JvmtiExport::at_single_stepping_point(JavaThread*, Method*, unsigned char*)+0x66  (jvmtiExport.cpp:1332)
V  [libjvm.so+0xed8398]  InterpreterRuntime::at_safepoint(JavaThread*)+0x118  (interpreterRuntime.cpp:1165)


But note this same issue can happen with other events, the test is just checking for single step.

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

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