Understanding the performance of my FFI-based API

[Alan Paxton]

Hi Maurizio,

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.

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.

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.

--Alan

On Thu, Mar 9, 2023 at 12:08 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Also, zooming into the benchmark, something funny seems to be going on
> with "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).
>
> 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.
>
> 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.
>
> Cheers
> Maurizio
> On 09/03/2023 11:29, Maurizio Cimadamore wrote:
>
> Hi Alan,
> 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.
>
> 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.
>
> Cheers
> Maurizio
>
> On 09/03/2023 11:15, Alan Paxton wrote:
>
> Hi,
>
> I hope this is an appropriate list for this question.
>
> 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.
>
> 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 ?
> Or is the performance likely to improve between the preview in Java 19 and
> release in Java 21 ?
> If there are resources or suggestions that would help me dig into the
> performance I'd be very grateful to be pointed to them.
>
> 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.
>
> These are links to the PR and some documentation of the work:
>
> https://github.com/facebook/rocksdb/pull/11095
>
> https://github.com/alanpaxton/rocksdb/blob/eb-1680-panama-ffi/java/JavaFFI.md
>
> Many thanks,
> Alan Paxton
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230309/5e92a962/attachment.htm>