Obsoleting JavaCritical

[David Holmes]

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