This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-01-24
Channels
- # announcements (22)
- # babashka (33)
- # babashka-sci-dev (161)
- # beginners (25)
- # calva (57)
- # cider (6)
- # clara (6)
- # clerk (14)
- # clj-kondo (24)
- # clojars (10)
- # clojure (65)
- # clojure-austin (1)
- # clojure-conj (2)
- # clojure-europe (23)
- # clojure-miami (3)
- # clojure-nl (3)
- # clojure-norway (3)
- # clojure-uk (3)
- # clojurescript (28)
- # cursive (24)
- # datomic (136)
- # emacs (38)
- # graalvm (29)
- # graphql (3)
- # introduce-yourself (8)
- # jackdaw (4)
- # jobs-discuss (9)
- # malli (5)
- # nbb (36)
- # off-topic (11)
- # pathom (58)
- # polylith (2)
- # practicalli (1)
- # re-frame (5)
- # reagent (11)
- # releases (1)
- # remote-jobs (8)
- # sci (15)
- # shadow-cljs (31)
- # slack-help (2)
- # spacemacs (11)
- # sql (7)
- # tools-build (9)
Graal 22.3.1 released, changelog https://www.graalvm.org/release-notes/22_3/#2231, nothing that relevant AFAICS
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
Super minimal example of using JNA with native-image, https://github.com/phronmophobic/jna-native-image. It seems to work!
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
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
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
And now the JNA test...$ 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]
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
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
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
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.