Obsoleting JavaCritical

[Wojciech Kudla]

> Yes for System.nanoTime(), but System.currentTimeMillis() reports
CLOCK_REALTIME.

Unfortunately System.currentTimeMillis() offers only millisecond
granularity which is the reason why our industry has to resort to
clock_gettime.
Agreed on the nature of this capability and possible consequences. You can
already use a single line of JNI or Unsafe to crash the JVM but this is
clearly signalled by the platform's documentation and been the status quo
for a very long time.
There are groups of developers competent enough to extract a lot of value
from consciously running with scissors.

I've had a look at the discussions and ideas pointed to by Maurizio and
agree with you David, that intrinsifying/inlining on demand would be ideal
here.
So far this has only been possible by forking Openjdk. Are there any plans
to allow this in a pluggable way?
It looks like Vladimir Ivanov was on the right track:
http://mail.openjdk.java.net/pipermail/panama-dev/2015-December/000225.html

Thanks,
W.

On Mon, Jun 6, 2022 at 7:45 AM David Holmes <david.holmes at oracle.com> wrote:

> On 6/06/2022 4:34 pm, Wojciech Kudla wrote:
> > 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.
>
> Yes for System.nanoTime(), but System.currentTimeMillis() reports
> CLOCK_REALTIME.
>
> This CriticalJNINatives mechanism was not intended for general use and
> was not supported in any real sense. If your "critical" native does not
> behave well then it can cause issues with GC and safepoints in general.
> A supported mechanism needs to be at least moderately safe (this is
> native code so full safety is not achievable), but it would come down to
> convention more than enforcement. And as raised in other threads on
> this, perhaps what is really wanted is a way to inline, or intrinsify,
> your own native code, rather than just trying to make slow native calls
> slightly faster.
>
> Cheers,
> David
> -----
>
> > 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
> >>
>