Awesome. I wonder how well this works on a stock JDK10 using graal.<p>Whenever I see a speed boost to do what is conceptually the same thing I'm always curious where the fat was cut. What did we give up? You can dump the resulting assembly with
-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly and diff might be revealing.<p>My hunch is that the line from the tutorial: `@CFunction(transition = Transition.NO_TRANSITION)`
makes all the difference. Explanation of NO_TRANSITION from [0]:<p>No prologue and epilogue is emitted. The C code must not block and must not call back to Java. Also, long running C code delays safepoints (and therefore garbage collection) of other threads until the call returns.<p>Which is probably great for BLAS-like calls. This lines up with my understanding from Cliff Click's great talk "Why is JNI Slow?"[1] basically saying that to be faster you need make assumptions about what the native code could and couldn't do and that generally developers would shoot themselves in the foot.<p>[0]: <a href="https://github.com/oracle/graal/blob/master/sdk/src/org.graalvm.nativeimage/src/org/graalvm/nativeimage/c/function/CFunction.java" rel="nofollow">https://github.com/oracle/graal/blob/master/sdk/src/org.graa...</a>
[1]: <a href="https://www.youtube.com/watch?v=LoyBTqkSkZk" rel="nofollow">https://www.youtube.com/watch?v=LoyBTqkSkZk</a>
Back in the day, GCC's Java native compiler "GCJ", had an alternative native method interface called CNI.<p>GCC recognized <i>#extern "Java"</i> in headers generated from class files. You could then call (gcj-compiled) Java classes from C++ as if they were native C++ classes, as well as implement Java "native" methods in natural C++.<p>The whole thing performed a lot better than JNI since it was, more or less, just using the standard platform calling conventions. Calling a native CNI method from Java had the same overhead as any regular Java virtual method call.<p>Ultimately, GCJ faded away because there wasn't a great deal of interest in native Java compilation back then, and too many compatibility challenges in the pre-OpenJDK days. But it's interesting to see many of it's ideas coming back now in the form of Graal/GraalVM.
There's an effort to bring a more modern FFI to Java that works similar to the one described in the article, called project Panama. It has tools to convert C header files into the equivalent annotated Java definitions and is intended to help improve performance as well.<p>You can follow along here:<p><a href="http://mail.openjdk.java.net/pipermail/panama-dev/" rel="nofollow">http://mail.openjdk.java.net/pipermail/panama-dev/</a><p>The same project is also adding support for writing vector code in Java (SSE, AVX etc).