Obsoleting JavaCritical

[Wojciech Kudla]

Thank you Maurizio,

We're hopeful things will improve with time in the next few Java releases
and can afford to stick to JDK17 for the time skipping a two or three
versions down the road if that means maintaining performance levels our
industry requires.
As for intrinsified calls: sadly System.nanoTime() is not an alternative to
clock_gettime(CLOCK_REALTIME) as they return different time. The JDK
obtains CLOCK_MONOTONIC IIRC.

Thanks,
W.

On Sun, Jun 5, 2022 at 10:52 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> (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
>