Obsoleting JavaCritical

[Wojciech Kudla]

Hi everyone,

Just wanted to let you know that obsoleting Critical JNI natives is going
to have a very detrimental impact on performance of latency-critical
software in a few domains like HPC, HFT or systematic market making.
We heavily exploit this feature and our use case has nothing to do with
arrays or otherwise slippery scenarios involving JVM-controlled memory. The
simplest example is calling clock_gettime(CLOCK_REALTIME) to get a high
resolution timestamp. Some shops in our industry also replace parts of NIO
with hand-crafted native code for example to get access to syscalls such as
recvmsg/recvmmsg (either to get hardware timestamps or batch receive or any
other functionality otherwise unavailable in the JDK.

JavaCritical_ variant of the native implementation is nearly 30% faster for
extremely short calls like the cases mentioned above compared to the
standard JNI impl. In case of clock_gettime(CLOCK_REALTIME) it's 23 nanos
vs 33 nanos on my box but I assure you we make a large number of such calls
in our industry and this just compounds.
Luckily with jdk17 we can still run with -XX:+CriticalJNINatives and get
the desired performance but I just checked a jdk18 build and the cost of
these calls is back at 33 nanos so this is performance regression.

JavaCritical is an important part of making Java successful in high
performance-focused areas and taking a step back with more restrictive
approach in Panama would be a blow to the perception of the platform and
its value in our field. I'd be more than happy to provide more context if
needed. I realize things are fluid and there's probably still a lot of work
in progress, but wanted to make you guys aware JavaCritical is not some
forgotten feature no one uses. There's a whole industry and scientific
research that relies on this.

Thanks,
Wojciech Kudla