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

[David Holmes]

On Mon, 24 Feb 2025 02:06:08 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.
>
>> 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
> 
> That sounds reasonable but we must also not post any events if we are suspended, which means we have to have checks that there are no locks held if are going to do this deferred suspension. 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? I'm still missing the complete big picture here.

Or should we simply be passing `allow_suspend=true` into more `ThreadBlockInVM` transitions?

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

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