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