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

[Serguei Spitsyn]

On Mon, 22 Dec 2025 01:32:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

> That isn't really any better to me. The general purpose handshake code should not have to be JNI-critical aware.

Agreed. It is not easy to track what was already discussed in this chat. Most likely, you already touched this but just wanted to double check. This issue is not fixable on the handshake code side. At the time the `SuspendThreadHandshakeClosure` op is executed, the target thread can be in native but not executing JNI critical region yet. However, after the `SuspendThreadHandshakeClosure` op has been finished (the suspend has been completed from the suspender point of view) the target thread can enter a JNI critical region while still in native and before having any chance to be self-suspended with the`ThreadSelfSuspensionHandshakeClosure`.
In opposite, the JNI-critical code can to be JVMTI suspend aware. It can block on entering JNI critical region while the thread is suspended. However, this approach can cause new deadlocks. Good news is that the debug agent does not use JNI critical regions (AFAIKS).

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

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