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

David Holmes dholmes at openjdk.org
Thu Dec 18 21:29:53 UTC 2025


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.

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

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

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


More information about the serviceability-dev mailing list