Obsoleting JavaCritical

[Maurizio Cimadamore]

Hi Wojciech,
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?

Regards
Maurizio

On 13/06/2022 21:38, Wojciech Kudla wrote:
> Hi Mark,
>
> Thanks for your input and apologies for the delayed response.
>
> > If the platform included, say, an intrinsified System.nanoRealTime()
> method that returned clock_gettime(CLOCK_REALTIME), how much would
> that help developers in your unnamed industry?
>
> 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.
>
> > In a similar vein, if people are finding it necessary to “replace parts
> of NIO with hand-crafted native code” then it would be interesting to
> understand what their requirements are
>
> 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).
> 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.
> Hope this does better job at explaining where we're coming from than 
> my previous messages.
>
> Thanks,
> W
>
> On Tue, Jun 7, 2022 at 6:31 PM <mark.reinhold at oracle.com> wrote:
>
>     2022/6/6 0:24:17 -0700, wkudla.kernel at gmail.com:
>     >> 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.
>
>     If the platform included, say, an intrinsified System.nanoRealTime()
>     method that returned clock_gettime(CLOCK_REALTIME), how much would
>     that help developers in your unnamed industry?
>
>     In a similar vein, if people are finding it necessary to “replace
>     parts
>     of NIO with hand-crafted native code” then it would be interesting to
>     understand what their requirements are.  Some simple enhancements to
>     the NIO API would be much less costly to design and implement than a
>     generalized user-level native-call intrinsification mechanism.
>
>     - Mark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20220629/870d5258/attachment-0001.htm>