JDK-8233343 : Deprecate -XX:+CriticalJNINatives flag which implements JavaCritical native functions
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 14,16
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-10-31
  • Updated: 2021-08-23
  • Resolved: 2020-10-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 16
16 b21Fixed
Related Reports
CSR :  
JDK-8254694 - Deprecate -XX:+CriticalJNINatives flag which implements JavaCritical native functions
Relates :  
JDK-8254693 - Add Panama feature to pass heap segments to native code
Relates :  
JDK-8258192 - Obsolete the CriticalJNINatives flag
Relates :  
JDK-8272838 - Move CriticalJNI tests out of tier1
Relates :  
JDK-7013347 - allow crypto functions to be called inline to enhance performance
Relates :  
JDK-8200388 - AArch64: Critical native support not fully implemented
Relates :  
JDK-8256746 - gc/CriticalNativeArgs.java fails without -XX:-CriticalJNINatives
Relates :  
JDK-8238861 - Remove suspend_flag
Relates :  
JDK-8229895 - Avoid GC lock when no array parameters are passed to critical native
Relates :  
JDK-8231554 - JEP 362: Deprecate the Solaris and SPARC Ports
Relates :  
JDK-8199919 - Deprecate JNI critical APIs
Description
This flag allows native functions to access Java heap primitive arrays as if they are in Java mode.  This was added for an optimization to specific sparc crypto functions, hence the restricted API.

We should deprecate the flag and later remove this support when project Panama is available.

  product(bool, CriticalJNINatives, true,                                   \
          "Check for critical JNI entry points")                            \
                                                                            \
  notproduct(bool, StressCriticalJNINatives, false,                         \
          "Exercise register saving code in critical natives")              \
                                                                            \
Also remove StressCriticalJNINatives.
Comments
Changeset: 56ea490f Author: Coleen Phillimore <coleenp@openjdk.org> Date: 2020-10-21 20:33:24 +0000 URL: https://git.openjdk.java.net/jdk/commit/56ea490f
21-10-2020
I also added an RFE to replace this functionality (not copying primitive array memory from the heap when calling native functions in panama).
13-10-2020
Reopening: The CriticalJNINative or JavaCritical functionality can be replaced with Panama. While deprecating this feature, we can remove the lazy critical safepoint code if we allow the JavaCritical native functions to run without transitioning to "native". This also effectively blocks GC, and other safepoints. Nothing in the JDK uses JavaCritical. Users that found this internal feature are writing native code that promises not to run a long time: https://stackoverflow.com/questions/36298111/is-it-possible-to-use-sun-misc-unsafe-to-call-c-functions-without-jni/36309652#36309652 Also, as this benchmark shows, CriticalNative is only really performant for native functions with short arrays. From JDK-8229895 the use case of interest has no parameters (passes dummy arrays). This use case will be replaced with Panama. I'll write a CSR.
09-09-2020
According to Robbin's microbenchmark, comparing a JavaCritical method to native code that uses GetPrimitiveArrayCritical, this code only gets very good numbers for its specific case if the typeArray is 256 elements or less. Natives.arrayElementsCritical 16 thrpt 3 5673373.787 ± 442563.904 ops/s Natives.arrayElementsCritical 256 thrpt 3 1009462.469 ± 54808.061 ops/s Natives.arrayElementsCritical 4096 thrpt 3 72102.668 ± 6536.017 ops/s Natives.arrayElementsCritical 65536 thrpt 3 4525.970 ± 1234.635 ops/s Natives.arrayElementsCritical 1048576 thrpt 3 287.979 ± 54.091 ops/s vs. Natives.javaCritical 16 thrpt 3 13787148.592 ± 223637.529 ops/s Natives.javaCritical 256 thrpt 3 1134644.718 ± 22981.952 ops/s Natives.javaCritical 4096 thrpt 3 72874.982 ± 7981.472 ops/s Natives.javaCritical 65536 thrpt 3 4558.510 ± 403.238 ops/s Natives.javaCritical 1048576 thrpt 3 286.637 ± 48.682 ops/s I had to write an avg c program to compare: difference for ArrayElementsCritical vs JavaCritical 16 length 5673373.787000 vs. 13787148.592000 difference 143 percent 256 length 1009462.469000 vs. 1134644.718000 difference 12 percent 4096 length 72102.668000 vs. 72874.982000 difference 1 percent 65536 length 4525.970000 vs. 4558.510000 difference 0 percent 1048576 length 287.979000 vs. 286.637000 difference 0 percent
27-08-2020
Closing as WNF. People might be using this feature on platforms other than solaris and we don't know.
22-11-2019
https://stackoverflow.com/questions/36298111/is-it-possible-to-use-sun-misc-unsafe-to-call-c-functions-without-jni/36309652#36309652 "I don't plan to use that commercially of course. I'm not even a professional, I just really enjoy coding and I've been studying CUDA lately so I thought maybe I could experiment with mixing everything together, but the overhead of JNI calls would defeat the purpose of having GPU accelerated code."
08-11-2019
This is even more reason to add a deprecated message sooner rather than later.
05-11-2019