JDK-8199919 : Deprecate JNI critical APIs
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: linux
  • CPU: x86_64
  • Submitted: 2018-03-21
  • Updated: 2019-11-08
  • Resolved: 2018-09-18
Related Reports
Relates :  
JDK-8233343 - Deprecate -XX:+CriticalJNINatives flag which implements JavaCritical native functions
Relates :  
JDK-8202604 - Use object pinning to avoid array copying in JNI_GetxxxArrayElements/GetStringxxx
Description
A DESCRIPTION OF THE REQUEST :
JNI criticals are complex enough that they have been broken in many Java releases when used with -Xcheck:jni:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-December/029523.html
They are a source of time to safepoint (TTSP) issues described as a "silent killer":
https://groups.google.com/d/msg/mechanical-sympathy/f3g8pry-o1A/x6NptTDslcIJ
There is an assumption that they provide un-copied access to memory which the API doesn't guarantee.
JVMs differ in how they are implemented meaning that performance guarantees don't exist, acquiring the critical lock may be a long pause for a JVM with a concurrent garbage collector running. Pinning may be a hard to measure cost in terms of memory fragmentation, cost to pin and GC overhead, etc.
Discouraging their usage will encourage improvements to libraries to write code in Java and avoid needless JNI transitions for the sake of "a quick copy".

JUSTIFICATION :
Deprecating an API is a way of frowning upon its usage. JNI criticals have so many issues that their usage should be frowned upon.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Gradually code will migrate from JNI criticals to either safe alternatives, GetArrayElements, GetArrayRegion, or be rewritten in Java.
ACTUAL -
Users feel that JNI criticals are a magic O(1) performance backdoor that allows them to mix native and Java code without realizing the TTSP issues they are creating.
Comments
Triage: This is not on our current list of priorities. We will considered this feature if we receive additional customer requirements.
18-09-2018
There is no "deprecation" mechanism for JNI. We can't flag methods as deprecated or give programmatic warnings from the compiler if you use them. The documentation for these functions is already full of warnings: "If possible, the VM returns a pointer to the primitive array; otherwise, a copy is made. However, there are significant restrictions on how these functions can be used. After calling GetPrimitiveArrayCritical, the native code should not run for an extended period of time before it calls ReleasePrimitiveArrayCritical. We must treat the code inside this pair of functions as running in a "critical region." Inside a critical region, native code must not call other JNI functions, or any system call that may cause the current thread to block and wait for another Java thread. (For example, the current thread must not call read on a stream being written by another Java thread.) These restrictions make it more likely that the native code will obtain an uncopied version of the array, even if the VM does not support pinning. For example, a VM may temporarily disable garbage collection when the native code is holding a pointer to an array obtained via GetPrimitiveArrayCritical." This is very much as case of "programmer beware" but we assume JNI programmers are capable enough to understand the warnings and to evaluate the appropriateness of the use of these functions.
21-03-2018