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

David Holmes dholmes at openjdk.org
Thu Jan 15 11:53:58 UTC 2026


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

Somehow I missed this PR before now so need to take a look.

src/hotspot/share/prims/jniCheck.cpp line 218:

> 216:     tty->print_cr("%s", fatal_other_function_in_critical);
> 217:     // Ideally the following, but at least AWT code triggers this (ouch!):
> 218:     // NativeReportJNIFatalError(thr, fatal_other_function_in_critical);

So it isn't fatal it is still just a warning.

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

PR Comment: https://git.openjdk.org/jdk/pull/29206#issuecomment-3754338824
PR Review Comment: https://git.openjdk.org/jdk/pull/29206#discussion_r2694082591


More information about the hotspot-dev mailing list