RFR: 8375209: Strengthen Xcheck:jni for JNI critical regions [v3]

[David Holmes]

On Wed, 14 Jan 2026 10:22:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8375188](https://bugs.openjdk.org/browse/JDK-8375188) shows that misuse for JNI critical is able to deadlock the GC. Therefore, I think we really want to have `-Xcheck:jni` to preempt these cases and allow us to diagnose the issues in the field.
>> 
>> G1 and Shenandoah are not exactly affected by this deadlock. ZGC never had this check, AFAICS, and is affected by the deadlock. We used to have some capability in Serial/Parallel prior to [JDK-8192647](https://bugs.openjdk.org/browse/JDK-8192647), AFAICS: https://github.com/openjdk/jdk/commit/a9c9f7f0cbb2f2395fef08348bf867ffa8875d73#diff-d27fc793db1bf9314b322d494cd1c3269629fe27a605b4441de08d543d020fc3L341-L344
>> 
>> Additional testing:
>>  - [x] New test, 100x repetitions
>>  - [ ] Linux x86_64 server fastdebug, `all` with `-XX:+UseParallelGC -Xcheck:jni`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Capture bad state at the end of JNI transition, check criticality on JNI function enters
>   Move the check to native->Java transition

I think warning that the native code that has started a critical region either returns (to Java) whilst the critical region is still active, or calls another JNI function, is a good thing. The return part has to be handled by the native call wrapper mechanics unfortunately. The JNI calls can be handled by augmenting the JNI entry macros. I would look at doing that rather than making this GC-centric or trying to handle it at the thread-state-transitions (assuming we can issue a JNI warning whilst still _thread_in_native).

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

PR Comment: https://git.openjdk.org/jdk/pull/29206#issuecomment-3757087207