Include libffi for fast, efficient integration with dynamic c libraries #1011
Replies: 7 comments 10 replies
-
|
Yes, this sounds like a very useful addition! One edge case may be the static (musl) compiled version of bb, not sure if that can use libffi as well. Happy to collaborate with you on that. |
Beta Was this translation helpful? Give feedback.
-
|
Awesome. I'll be on vacation for the next two weeks, but I'll hopefully have some time in the second half of this month. |
Beta Was this translation helpful? Give feedback.
-
|
Initial proof of concept for an ffi interface, https://github.com/phronmophobic/babashka/tree/ffi. The wrapper for libffi is here, https://github.com/phronmophobic/clj-libffi. Currently, it will only work on Mac OSX, but it shouldn't be too much work to add support for linux and windows. Compiling with out including libffi was ~80mb and adding the libffi namespace increased it to about ~148mb. That seems like a lot, but it does provide access to a wide ecosystem of c libraries or java libraries compiled to shared libraries with native-image. Not sure where most of the bulk is coming from, but it might be possible to strip some of the dtype-next dependencies down or implement the interface directly to reduce the size. bash-3.2$ ./bb
Babashka v0.6.2-SNAPSHOT REPL.
Use :repl/quit or :repl/exit to quit the REPL.
Clojure rocks, Bash reaches.
user=> (require '[babashka.ffi :as ffi])
nil
user=> (ffi/call "cos" :float64 :float64 42)
-0.3999853149883513
user=> (ffi/load-library "/usr/lib/libobjc.A.dylib")
#object[tech.v3.datatype.ffi.Pointer 0x35d0b188 "{:address 0x0000000209E72990 }"]
user=> (ffi/call "objc_getClass" :pointer :pointer (ffi/string->c "NSArray"))
#object[tech.v3.datatype.ffi.Pointer 0x4cf726a "{:address 0x00007FFF883B8A70 }"]Even if calling c libraries would be technically possible with this version, there's still open questions as how to make it easy for babashka users to obtain and call c libraries. Always more to do! Any thoughts on what you see so far? |
Beta Was this translation helpful? Give feedback.
-
|
@cnuernber This looks pretty interesting ^ |
Beta Was this translation helpful? Give feedback.
-
|
This is very awesome work. I will study it more in the weekend. The binary size is a bit concerning, but we can at the very least make an experimental SCI-based tool where we incorporate this and see how it evolves. Also with respect to building other Clojure libraries as shared libs. Would it be possible to pass function references over the native FFI border for example? I would be surprised if this was possible. |
Beta Was this translation helpful? Give feedback.
-
Sounds good. It looks like many of the included bb libraries have a small surface area. There might also be a way to remove more builtin libs and provide them as shared libraries. There's definitely some backwards compatibility and procurement issues that would need to be solved, but it might be a reasonable way to make |
Beta Was this translation helpful? Give feedback.
-
I also doubt that this is possible. |
Beta Was this translation helpful? Give feedback.
-
|
Right. We can just start from a small SCI core and then try to add some namespaces as shared libs and see how that goes. |
Beta Was this translation helpful? Give feedback.
-
|
Also there is truffle native interface |
Beta Was this translation helpful? Give feedback.
-
|
I did not know that existed! That seems better than my approach with libffi via graalvm's native interface. I'll give that a shot and see if it reduces the binary size. |
Beta Was this translation helpful? Give feedback.
-
|
Do you know of an example (either java or clj) that uses the truffle native interface? I'm having trouble figuring out how to set things up.
I can't even find an example on the internet 🤷 It's still marked as experimental, so it might also be worth revisiting this in the future:
|
Beta Was this translation helpful? Give feedback.
-
|
I know you have to include some special arguments to include it - it is a separate module similar to https. I haven't directly tried to get nfi to work myself. |
Beta Was this translation helpful? Give feedback.
-
|
@phronmophobic Hey, I figured, we could include this behind a feature flag for people who want to have this today. https://github.com/babashka/babashka/blob/master/doc/build.md#feature-flags What do you think of that idea? Also with Java 17 in mind, I wonder if there will be new possibilities using Panama or so. |
Beta Was this translation helpful? Give feedback.
-
|
Including as a feature flag makes a lot of sense. There's still some significant caveats to the current version:
On the bright side, dtype-next should now support clj-easy/graal-build-time, cnuernber/dtype-next#41 |
Beta Was this translation helpful? Give feedback.
-
I'm pretty excited about the potential for Panama. Hopefully, it means you can get libffi features with native-image for free! |
Beta Was this translation helpful? Give feedback.
-
|
We can mark it as as very experimental so users can use it with these caveats. |
Beta Was this translation helpful? Give feedback.
-
|
From what I could tell, Java 22 will probably include panama final version. |
Beta Was this translation helpful? Give feedback.
-
Is your feature request related to a problem? Please describe.
The main options for adding an additional library to bb are:
Including libffi would be an alternative to babashka pods. The main benefits of using libffi over pods are:
Describe the solution you'd like
The basic idea is that you can load and call functions from a dynamic library at runtime using libffi.
Describe alternatives you've considered
Babashka pods already provide an alternative. However, there are many existing libraries that already are c ABI compatible. Additionally, using pods can have meaningful overhead for certain applications.
Additional context
This is a pretty experimental idea, but I think it could unlock a lot of value. If this feature sounds interesting, I could start gathering more info to determine if it's actually a good fit. I would also be interested in doing the bulk of the integration work. I've been thinking about how to script UIs with membrane, and this seems like one of the better options.
I know that binary size is an important factor for bb. libffi.a on mac osx is 53kb and I assume there's some additional size required for integrating it.
It's also possible that
native-imagewill include libffi-like functionality directly in the future.Beta Was this translation helpful? Give feedback.
All reactions