Open franz1981 opened 2 years ago
And, very importantly: https://bugs.openjdk.org/browse/JDK-8258192
This is marked for removal till project Panama will be available (but planned, not yet happened IIUC)
I'm skeptical about how much of a difference it'll make, since the system calls into the kernel have overhead already. We could try with one of the transports and see what the benchmarks say.
You might want to check this out: https://github.com/apangin/nalim
@slandelle yep I believe @apangin has followed our conversations on twitter about it :) That guy is incredible 🤣
You might want to check this out: https://github.com/apangin/nalim
Whoa this is pretty cool 🤯
I realized nalim is GPL'd. Sounds like we can't refer to its API such as @Link
, @Code
and Linker.linkClass()
? Any chance @apangin relicenses the project under more permissive one? (~Could leave the agent part under GPL though~)
Created a separate issue to track this idea - https://github.com/apangin/nalim/issues/7
We can still have an incubator and help the Panama folks to get their current solution on par of the critical native/nalim solution too, to make the whole Java ecosystem to benefit about it... I can reach some of the RedHat/Oracle folks if @normanmaurer @chrisvest know anyother on Apple to reach out
Note: I am big fan of the Andrei's work eh, but if we can bring it to the wider audience, we have more chance to get it supported for longer time, without relying on a single person
I agree with @franz1981 that it'd be great if Panama reaches the performance of JNI Critical Native or Nalim and if we could help them achieve that.
One thing that makes nalim a better solution is that JVMCI is already available since Java 9 while we need newer Java to use Panama. Even after Panama is ready, JVMCI will probably be still there.
Recent benchmarks (based on Java 21 snapshot) shows Panama performing better than JNI in many cases: https://github.com/Glavo/java-ffi-benchmark
JNI calls can be faster by respecting the JDK definition of Critica Native functions: see https://github.com/franz1981/jdk11/blob/a060be188df894ed5c26fc12fc9e902f9af32bd3/src/hotspot/share/prims/nativeLookup.cpp#L277
and SO at https://stackoverflow.com/questions/36298111/is-it-possible-to-use-sun-misc-unsafe-to-call-c-functions-without-jni/36309652#36309652
Many of our epoll JNI methods (writev/recv/send) already use
jlong
vs buffer refs, meaning that they can be transformed in Critical Native functions, or at least explore if it's possible to do it.