[jdk19] RFR: 8289302: Restore CriticalJNINatives

[Robbin Ehn]

On Wed, 29 Jun 2022 12:10:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change restores the code in the JVM that implemented the internal JavaCritical or CriticalJNINatives functionality.  Customers are using this feature and there's no replacement yet for it.
> This change is a backout and merge of jDK-8258192: Obsolete the CriticalJNINatives flag.
> This change also adds the deprecation message that was missed, which I checked is okay with the customer.
> 
> Tested with tiers1-4.

Note that if there is a safepoint or handshake without JavaCritical the JavaThread may be stopped for such on the back edge of the call. Which means if you measure the time from Java you also including time spend in safepoint/handshake in such case.

We measure using https://github.com/openjdk/jmh, which can control for such events.
Here are some example of our numbers:

########### BASELINE JDK17 ##########
Benchmark - Iterations: 100000000 total time:3446158970 ns ; Per op:34.4615897
Benchmark - Iterations: 100000000 total time:3481146574 ns ; Per op:34.81146574
Benchmark - Iterations: 100000000 total time:3432662217 ns ; Per op:34.32662217
########### CRITICAL JDK17 ##########
Benchmark - Iterations: 100000000 total time:2695102198 ns ; Per op:26.95102198
Benchmark - Iterations: 100000000 total time:2707413238 ns ; Per op:27.07413238
Benchmark - Iterations: 100000000 total time:2604335910 ns ; Per op:26.0433591
###########  UseSystemMemoryBarrier JDK17 ##########
Benchmark - Iterations: 100000000 total time:2930762287 ns ; Per op:29.30762287
Benchmark - Iterations: 100000000 total time:2874010646 ns ; Per op:28.74010646
Benchmark - Iterations: 100000000 total time:2817695430 ns ; Per op:28.1769543

Note that we accidentally optimized JavaCritical in JDK 17, so UseSystemMemoryBarrier should be on par with pre-JDK-17.

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

PR: https://git.openjdk.org/jdk19/pull/90