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

[Axel Boldt-Christmas]

On Tue, 13 Jan 2026 19:44:23 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:
> 
>   Terminology

Ideally `Xcheck:jni` should identify transitions which could respond to a GC, regardless of GC implementation. `native -> vm` transition will as far as I can tell poll for safepoints even if it is in a JNI critical region. 

This currently is an issue with `Release*Critical` which has a `native -> vm` transition before releasing the critical region. And the fact that we allow for nested critical regions. So the two consecutive calls to `Get*Critical` will have a `native -> vm` transition in the second call. 

I did some quick and dirty prototyping of a solution for this a while back https://github.com/openjdk/jdk/compare/master...xmas92:jdk:fix-jni-critical

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

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