<div dir="ltr">Hi Maurizio,<div><br></div><div>Thanks for the quick and detailed response. I think our goals coincide as it would make life easier for rocksjava to successfully implement an FFI API.</div><div><br></div><div>A couple of quick initial reruns shows me your suggestions both contribute a small amount of improvement, but probably do not account for all the performance I am missing. I shall rerun the full benchmark for confirmation.</div><div><br></div><div>And since both suggestions give me a clearer idea what might be performance issues, I will take another pass over my code and see if I can spot any other potential problems in how it's implemented, or anything else that isn't truly like-for-like with the JNI version.</div><div><br></div><div>--Alan</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 9, 2023 at 12:08 PM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com">maurizio.cimadamore@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">

  
  <div>
    <p>Also, zooming into the benchmark, something funny seems to be
      going on with "<span>getKeySegment". This seems
        different from the "getKeyArr" counterpart, but also has a new
        issue: I believe that, in JNI, you just passed the Java array
        "as is" - but in Panama you can't (as the array is on-heap), so
        there is some double-copying involved there (e.g. you create an
        on-heap array, which then is moved off-heap).</span></p>
    <p><span>If I'm not mistaken, this method is executed
        on every benchmark iteration, so the comparison doesn't just
        mesure the cost of the native call, but also the cost it takes
        to marshal data from Java heap to native.</span></p>
    <p><span>For instance, the byte buffer versions
        ("keyBuf") seem to avoid this problem by copying the data
        directly off-heap (by using a direct buffer). I think the
        benchmark should use a native segment, and avoid the copy so
        that at least we avoid that source of noise in the numbers.</span></p>
    <p><span>Cheers<br>
        Maurizio<br>
      </span></p>
    <div>On 09/03/2023 11:29, Maurizio
      Cimadamore wrote:<br>
    </div>
    <blockquote type="cite">Hi
      Alan,
      <br>
      first of all, I'd like to thank you for taking the time to share
      your experience and to write it all up in a document. Stuff like
      that is very valuable to us, especially at this stage in the
      project.
      <br>
      <br>
      One quick suggestion when eyeballing your code: your method
      handles are "static", but not "final". I suggest you try to
      sprinkle "final" in, and see whether that does the trick. If not,
      we'd have to look deeper.
      <br>
      <br>
      Cheers
      <br>
      Maurizio
      <br>
      <br>
      On 09/03/2023 11:15, Alan Paxton wrote:
      <br>
      <blockquote type="cite">Hi,
        <br>
        <br>
        I hope this is an appropriate list for this question.
        <br>
        <br>
        I have been prototyping an FFI-based version of the RocksDB Java
        API, which is currently implemented in JNI. RocksDB is a C++
        based key,value-store with a Java API layered on top. I have
        done some benchmarking of the FFI implementation, versus the JNI
        version and I find it performs consistently slightly slower than
        the current API.
        <br>
        <br>
        I would like to understand if this is to be expected, e.g. does
        FFI do more safety checking under the covers when calling a
        native method ?
        <br>
        Or is the performance likely to improve between the preview in
        Java 19 and release in Java 21 ?
        <br>
        If there are resources or suggestions that would help me dig
        into the performance I'd be very grateful to be pointed to them.
        <br>
        <br>
        For the use case I'm measuring, data is transferred in native
        memory originally allocated by RocksDB in C++ which I wrap as a
        MemorySegment; I do allocate native memory for the request
        structure.
        <br>
        <br>
        These are links to the PR and some documentation of the work:
        <br>
        <br>
        <a href="https://github.com/facebook/rocksdb/pull/11095" target="_blank">https://github.com/facebook/rocksdb/pull/11095</a>
        <br>
<a href="https://github.com/alanpaxton/rocksdb/blob/eb-1680-panama-ffi/java/JavaFFI.md" target="_blank">https://github.com/alanpaxton/rocksdb/blob/eb-1680-panama-ffi/java/JavaFFI.md</a>
        <br>
        <br>
        Many thanks,
        <br>
        Alan Paxton
        <br>
        <br>
      </blockquote>
    </blockquote>
  </div>

</blockquote></div>