<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Hi Wojciech,<br>
picking up this thread again. After some internal discussion, we
realize that we don't know enough about your use case. While
re-enabling JNI critical would obviously provide a quick fix,
we're afraid that (a) developers might end up depending on JNI
critical when they don't need to (perhaps also unaware of the
consequences of depending on it) and (b) that there might actually
be _better_ (as in: much faster) solutions than using critical
native calls to address at least some of your use cases (that
seemed to be the case with the clock_gettime example you
mentioned). Could you please provide a rough list of the native
calls you make where you believe critical JNI is having a real
impact in the performance of your application? Also, could you
please tell us whether any of these calls need to interact with
Java arrays? In other words, do you use critical JNI to remove the
cost associated with thread transitions, or are you also taking
advantage of accessing on-heap memory _directly_ from native code?</p>
<p>Regards<br>
Maurizio<br>
</p>
<div class="moz-cite-prefix">On 13/06/2022 21:38, Wojciech Kudla
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CADV2yPkPgb3KH6BR=q4AUBMnXpojyKE8GdfM3rK46ZywV0rgGg@mail.gmail.com">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>Hi Mark,<br>
<br>
</div>
Thanks for your input and apologies for the delayed
response.<br>
<br>
> If the platform included, say, an intrinsified
System.nanoRealTime()<br>
method that returned clock_gettime(CLOCK_REALTIME), how
much would<br>
that help developers in your unnamed industry?<br>
<br>
</div>
Exposing realtime clock with nanosecond granularity in the
JDK would be a great step forward. I should have made it
clear that I represent fintech corner (investment banking
to be exact) but the issues my message touches upon span
areas such as HPC, audio processing, gaming, and defense
industry so it's not like we have an isolated case.<br>
<br>
> In a similar vein, if people are finding it necessary
to “replace parts<br>
of NIO with hand-crafted native code” then it would be
interesting to<br>
understand what their requirements are<br>
<br>
</div>
As for the other example I provided with making very short
lived syscalls such as recvmsg/recvmmsg the premise is
getting access to hardware timestamps on the ingress and
egress ends as well as enabling batch receive with a single
syscall and otherwise exploiting features unavailable from
the JDK (like access to CMSG interface, scatter/gather,
etc).<br>
</div>
<div>There are also other examples of calls that we'd love to
make often and at lowest possible cost (ie. getrusage) but
I'm not sure if there's a strong case for some of these
ideas, that's why it might be worth looking into more
generic approach for performance sensitive code.<br>
</div>
<div>Hope this does better job at explaining where we're
coming from than my previous messages.<br>
</div>
<div><br>
</div>
Thanks,<br>
</div>
W<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Jun 7, 2022 at 6:31 PM
<<a href="mailto:mark.reinhold@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">mark.reinhold@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">2022/6/6
0:24:17 -0700, <a href="mailto:wkudla.kernel@gmail.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">wkudla.kernel@gmail.com</a>:<br>
>> Yes for System.nanoTime(), but
System.currentTimeMillis() reports<br>
>> CLOCK_REALTIME.<br>
> <br>
> Unfortunately System.currentTimeMillis() offers only
millisecond<br>
> granularity which is the reason why our industry has to
resort to<br>
> clock_gettime.<br>
<br>
If the platform included, say, an intrinsified
System.nanoRealTime()<br>
method that returned clock_gettime(CLOCK_REALTIME), how much
would<br>
that help developers in your unnamed industry?<br>
<br>
In a similar vein, if people are finding it necessary to
“replace parts<br>
of NIO with hand-crafted native code” then it would be
interesting to<br>
understand what their requirements are. Some simple
enhancements to<br>
the NIO API would be much less costly to design and implement
than a<br>
generalized user-level native-call intrinsification mechanism.<br>
<br>
- Mark<br>
</blockquote>
</div>
</blockquote>
</body>
</html>