Comparing the performance of Panama with JNI, JNA, and JNR - based on Java 21

[Maurizio Cimadamore]

On 27/03/2023 15:18, Glavo wrote:
> Another idea related to usability and performance: Can Panama provide 
> a thread-local "native stack" to help users allocate local variables?
>
> I have heard from others that LWJGL is using this technology. I also 
> tried to implement it:
>
>     https://github.com/Glavo/java-ffi-benchmark/blob/main/src/main/java/benchmark/experimental/NativeStack.java
>     <https://urldefense.com/v3/__https://github.com/Glavo/java-ffi-benchmark/blob/main/src/main/java/benchmark/experimental/NativeStack.java__;!!ACWV5N9M2RV99hQ!NGWKauzXDhIIf_DFibMiRXqyafDYTQ6yIYsFfxsvKbUzFcEhN8_U-A1W85dbMIgL3u_r0jcch-NtPT65nYWdXFdzHw$>
>
> I ran benchmarks where allocating a small number of local variables 
> was thirty times more efficient than using a confined arena.
> If Panama can provide such a class, it will be more convenient and 
> faster for users to assign temporary variables.

While the FFM API does not provide anything directly, it is easy to 
build such an arena on top of FFM.

https://github.com/openjdk/panama-foreign/blob/foreign-memaccess%2Babi/test/micro/org/openjdk/bench/java/lang/foreign/StrLenTest.java#L178

The above implementation is slightly simpler than what LWJGL does, but 
it provides a large boost (because it avoids all dynamic allocations).

More advanced implementations which allocate dynamically when out of 
space and then remember said allocation even after a "release" are also 
possible.

While we might add some such allocators in the future, the main priority 
of the FFM API, design-wise, has been to make sure that such custom 
arenas can be defined by developers directly, when and if needed.

And this is indeed the biggest shift from Java 19 (which doesn't allow 
custom arenas) to Java 20. Java 21 just iterates on the API, making it a 
little bit simpler to use again, while retaining the capability of 
defining custom arenas.

Maurizio

>
> Glavo
>
> On Sat, Mar 25, 2023 at 3:07 AM Glavo <zjx001202 at gmail.com> wrote:
>
>     I have run a series of benchmarks of Panama, JNI, JNA, and JNR
>     based on the latest JDK. Here is its GitHub repository:
>
>     https://github.com/Glavo/java-ffi-benchmark
>     <https://urldefense.com/v3/__https://github.com/Glavo/java-ffi-benchmark__;!!ACWV5N9M2RV99hQ!NGWKauzXDhIIf_DFibMiRXqyafDYTQ6yIYsFfxsvKbUzFcEhN8_U-A1W85dbMIgL3u_r0jcch-NtPT65nYWm3ZB9qA$>
>
>     Here I tested the performance of no-ops, accessing structs, string
>     conversions, and callbacks, respectively. I also tried the new
>     isTrivial linker option.
>     I summarized the results in README and charted them.
>
>     In this email, in addition to sharing the above results, I would
>     also like to talk about several issues I have encountered
>
>     1. MemorySegment.getUtf8String is unexpectedly slow
>
>         Panama is much faster than JNA in most cases, but the
>         operation of converting C strings to Java strings is an exception.
>         I checked the source code of JNA and Panama, and the
>         suspicious difference is that JNA uses strlen from the C
>         standard library, while Panama uses Java loops.
>         Perhaps this method can be optimized.
>
>
>     2. StructLayout must manually specify all padding
>
>         Can we provide a convenient method for automatically padding
>         between fields based on alignment?
>         The current structLayout method is annoying for situations
>         where you need to manually simulate the layout of a C struct.
>
>
>     Glavo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230327/303cb77a/attachment-0001.htm>