On Thu, 18 Dec 2025 19:26:55 GMT, Patricio Chilano Mateo <[email protected]> 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
