RFR: 8373839: Disable JVM TI suspension during JNI critical regions

[Patricio Chilano Mateo]

On Thu, 18 Dec 2025 19:26:55 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> To ensure JNI critical access to a raw array can't interfere with actions of the debugger, we disable JVM TI suspension whilst JNI critical access is active, as originally suggested by @fisk. We assume the debugger is being operated correctly (ie the thread using the raw array will be suspended), and that the critical section is short so as to not delay debugging too long. 
>> 
>> The mechanism for this already exists courtesy of the virtual thread support.
>> 
>> Testing:
>>  - tiers 1 - 6 sanity
>
> So this `_is_disable_suspend` flag will prevent the target from processing the async handshake and suspend, but the suspender will still consider the target suspended once `SuspendThreadHandshakeClosure` is done. We would need to check the state of the target and don't consider it "handshake safe" if it's in a JNI critical region.

> Thanks for looking at this @pchilano
> 
> > So this `_is_disable_suspend` flag will prevent the target from processing the async handshake and suspend, but the suspender will still consider the target suspended once `SuspendThreadHandshakeClosure` is done.
> 
> This two-step process always causes me confusion. So the "disabling" mechanism is not actually disabling anything from the requesters point of view. I don't understand what it is actually doing then? And I think I would like it called something else.
> 
It was added to prevent deadlocks while executing some critical sections in methods of the `VirtualThread` class. Don't remember if there was an issue with delaying the suspender instead.

> > We would need to check the state of the target and don't consider it "handshake safe" if it's in a JNI critical region.
> 
> So rather than "just" disabling suspension whilst in JNI critical your suggestion would delay all handshakes and safepoints which seems a far more risky proposition.
>
It would only be for suspend operations, as the PR is trying to address this specific issue with the debugger. I see that something like this was already suggested in the JBS comments for 8369515, and that there is an alternative suggestion to return a copy of the object. In any case my comment was mainly to point out we are not disabling suspension as intended and describe what would need to be done instead (or at least one of the two possible solutions).

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

PR Comment: https://git.openjdk.org/jdk/pull/28884#issuecomment-3672704793