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

[Glavo]

I added two test results, namely the case of disabling C2 (using C1) and
the case of disabling JIT compiler (only interpreter):

    https://github.com/Glavo/java-ffi-benchmark/tree/main/data/1

The purpose of these benchmarks is to understand the performance of Panama
during the warm-up phase or on the Client VM.

When using C1, Panama is usually much slower than JNI, but not inferior to
JNR, and still much faster than JNA.
One exception is the upcall stub, in which case Panama is still several
times faster than other solutions.

When using an interpreter, Panama is slower, even slower than JNA Direct
Mapping, but still a bit faster than regular use of JNA.

Well, this is not an unexpected result, after all, MethodHandle needs to be
fully optimized by the C2 compiler to have good performance.
While I wish its implementation on the interpreter was faster, even the
slower JNA is widely used, so the performance of Panama's warm-up phase is
still acceptable.

However, there is still a noteworthy issue: The strlen implementation I
optimized earlier is much slower on both C1 and interpreter than the old
implementation.
It seems that C1 has not optimized the Vector API. I think in order to
preheat the speed, the Vector API should not be used here, but should be
implemented as C1/C2 Intrinsic.

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
>
> 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/20230405/9672b626/attachment.htm>