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

[Patricio Chilano Mateo]

On Fri, 21 Feb 2025 03:17:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

>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.
>
Maybe we should just add a side function to check this and call it from all `JvmtiExport::post_xxx` methods.

>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.
>
In general we delay suspension until going back to Java or coming out of native, and avoid suspending in the transitions out of a blocked state because we could be holding VM monitors (JDK-8270085). This suspend check aims to address these cases where the thread was suspended sometime before while in a blocked state but it didn’t suspend when transitioning back to vm. So I don’t think there is an obvious better place to have it. Now of course we should check that we are not holding VM monitors in here, otherwise we are still in the same boat, but I see we already have a `!thread->owns_locks()` assert as part of `JvmtiJavaThreadEventTransition` due to `ThreadToNativeFromVM`. Some events use `JvmtiThreadEventTransition` though which does manual transitions and we don’t have a check there. We should move this `!thread->owns_locks()` check to `ThreadStateTransition` to cover all transitions to/from java and native but I’ll investigate that as a separate PR.

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

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