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

[Jorn Vernee]

Also note that there are potential issues when combining ThreadLocal and 
virtual threads, as there might be a very large number of threads, 
resulting in a very large number of NativeStack instances (along with 
their native memory stacks)

This makes supporting something based on ThreadLocal directly in the JDK 
more questionable I think, since it depends on the particular 
application whether this will work well, or not.

Jorn

On 27/03/2023 16:29, Maurizio Cimadamore wrote:
>
>
> 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/4e00e9a4/attachment-0001.htm>