JNI critical does not properly leave the VM when going to native (which can block for safepoints) and gives access to the heap directly in case of a primitive array.
JNI critical has been removed.
The primitive array case seems not be well known (good!) and we have not seen any concerns about that.
But the lack of faster JNI calls has been noted.
If we only need the faster transitions the best idea for it is to add back barrier-less transitions. It is almost as fast as JNI critical, but applies to all ordinary JNI methods. (JNI critical had simpler argument packing due to blocking safepoints)
This time we want to:
- Use documented and supported OS features.
- Leave it as an experimental feature, and document that it may be removed in any release without prior notice.
- is blocked by
-
JDK-8292592 JFR test TestNative is not reliable due to low rate of sampling.
-
- Resolved
-
- relates to
-
JDK-8295666 Linux x86 build fails after 8292591
-
- Resolved
-
-
JDK-8293771 runtime/handshake/SystemMembarHandshakeTransitionTest.java fails if MEMBARRIER_CMD_QUERY is unsupported
-
- Resolved
-
-
JDK-8303210 [linux, Windows] Make UseSystemMemoryBarrier available as product flag
-
- Resolved
-
-
JDK-8332253 Linux arm32 build fails after 8292591
-
- Resolved
-
-
JDK-8295395 Linux Alpha Zero builds fail after JDK-8292591
-
- Resolved
-
-
JDK-8321075 RISC-V: UseSystemMemoryBarrier lacking proper OS support
-
- Resolved
-
-
JDK-8293787 Linux aarch64 build fails after 8292591
-
- Closed
-
-
JDK-8289302 Restore CriticalJNINatives
-
- Closed
-
-
JDK-8293922 Extend barrier-less Java thread transitions to native transitions
-
- Resolved
-
-
JDK-8337657 AArch64: No need for acquire fence in safepoint poll during JNI calls
-
- Resolved
-