Obsoleting JavaCritical

[Maurizio Cimadamore]

(adding hotspot-dev)

Hi Wojciech,
it is not the goal of Project Panama to obsolete Critical JNI. What we 
would like to do is, obviously, over time, get to a similar level of 
performance (as discussed elsewhere in this mailing list recently, see [1]).

It is possible that there might be other ways to get to the same level 
(or better) of performance than the one you have (I understand that this 
is especially the case with clock_gettime, for which an intrinsified 
alternative is available in the JDK - System.nanoTime) - in general 
using native calls for things that only contains a bunch of machine 
instruction is always going to be painful.

That said, I'd like somebody on the hotspot team to add more background 
on the decision of dropping support for JNI critical in 18.

[1] - 
https://mail.openjdk.java.net/pipermail/panama-dev/2022-June/017046.html

On 05/06/2022 22:25, Wojciech Kudla wrote:
> 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