It might be relevant though, since the latest 22.3.0 JDK19 which has virtual threads contained a bug which is likely solved with 22.3.1

It's funny that the startup time is affected that much by JNA:

$ time target/jna
cosine of 42 is -0.39998531498835127
target/jna   0.00s  user 0.01s system 14% cpu 0.079 total

binary size seems ok

Yea, interesting. I wonder where all of the time is being spent. Loading JNA code? Loading the shared library?

I suspect binary size could be further improved since it's including native libs for several architectures, https://github.com/phronmophobic/jna-native-image/blob/main/config/resource-config.json#L9.

Not too much though. It seems like each lib is about 100-300kb

going to try dynamic SCI eval now

At least this works...

$ time ./target/jna -e '(+ 1 2 3)'
6
./target/jna -e '(+ 1 2 3)'   0.01s  user 0.01s system 81% cpu 0.016 total

$ time ./target/jna -e '(com.sun.jna.NativeLibrary/getInstance "c")'
Exception in thread "main" java.lang.UnsatisfiedLinkError: Unable to load library 'c':
com.sun.jna.Native.open(Ljava/lang/String;I)J [symbol: Java_com_sun_jna_Native_open or Java_com_sun_jna_Native_open__Ljava_lang_String_2I]

weird

I initialized com.sun.jna at build time - maybe this is the reason

I'm now undo-ing that

Ah, that makes sense

$ time ./target/jna -e '(com.sun.jna.NativeLibrary/getInstance "c")'
#object[com.sun.jna.NativeLibrary 0x9dc5a32 "Native Library <libc.dylib@20706503656>"]
./target/jna -e '(com.sun.jna.NativeLibrary/getInstance "c")'   0.01s  user 0.01s system 23% cpu 0.071 total

now the full cosine example...

I didn't make it explicit in the example, but it's sensitive to the type you call it with

so (cos 42.0) is ok, but (cos 42) will not work

$ time ./target/jna -e '(let [clib (com.sun.jna.NativeLibrary/getInstance "c") cos-fn (.getFunction clib "cos")] (.invoke cos-fn Double/TYPE (into-array Object [42.0]))) '
-0.39998531498835127

https://twitter.com/borkdude/status/1618006680662605831 ;)

This is really cool

I did an experiment with trying to make a generic interface that would use either the new Java FFI or the Native Image specific C FFI under the hood depending on if AOT compilation was happening or not but that was too much work for each specific case to be “fun” to work with. Probably very performant though. I wish the new Java FFI would work with Native Image. It didn’t when I tried.

@U89UL6P9P Have you tried asking in the GraalVM slack why it would't work? they have a native-image channel in there. I'm curious too

No, I didn’t have time to pursue it. I am sure I was just early. It’s still an incubation feature right? I am guessing they will support it. But there is a chance they will not because they have their own already.

They have their own for native image but it's painful two have to maintain two versions right. dtype.next also has an API that supports JVM + native-image I think

Yeah I hope it gets consolidated now that an official FFI is finally coming to Java.

dtype next supports graalvm, jna, and java17's java16's flavor of ffi. I don't think dtype supports the newer versions of panama (yet). edit: it looks like it's actually jdk-16's flavor of ffi.

I would also like to see these options consolidate. clojure let's you build interfaces that help isolate you from the various implementations, but there's still extra work involved.