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

Aleksey Shipilev shade at openjdk.org
Wed Jan 14 10:22:37 UTC 2026


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

Yes, it looks to me that there are "normal" native->VM transitions here and there. We can be more precise and check for JNI Critical state at the end of the actual JNI transition in interpreted/compiled adapters and native->Java transitions on VM side. This unfortunately means some checks are in platform-specific code.

See the new PR version for a stab at how that might look like. I'll run more tests to see if anything in JDK depends on current (broken) behavior.

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

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


More information about the hotspot-dev mailing list