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

[Chris Vest]

The JDK can use CarrierThreadLocal, so it's not a problem as long as the
usage scope of the thread-local values are tightly controlled, and don't
span across virtual thread context switches.

On Mon, Mar 27, 2023 at 8:59 AM Jorn Vernee <jorn.vernee at oracle.com> wrote:

> 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/68354a4f/attachment.htm>