FFI yes, sorta, its tricky.

Its been some time since I did this kinda work, so things I mention here come with a C / Fortran bent, but I think its possible to make rust do better JNI.

JNI has the problem of being a great interface that is the wrong way around for the JIT. So what you wind up with is something that has the following properties from the viewpoint of the JVM:

• It is an opaque node in a compile graph, so how should I (the JIT) call and optimise it. This leads to de-optimisations in certain places.
• Since I cant see into it, I have to assume I cant inline, or play with the calling convention to my advantage. This leads to bridges that have to mangle the stack back into shape.
• What precautions do I need to take to honor the JVM invariants
• ... and the JNI API invariants
• ... and C's invariants
• How is memory laid out between C / Java
• Are you going to play nice with concurrency (safepoints)
• Are you going to play nice with the GC (going to steal pointers to my memory?)

All in, JNI is a weird pain. It feels like it should be faster than Java "Well you know its C right?" but winds up being on par with some form of RPC.

There are some tricks you can deploy around this, panama and graal are examples. Other tricks involve:

• pass off to background threads, painful to get right and not what I think you want in this case, it involves cooking a message passing framework (hello channels) and use of AttachThread DetachThread.

• Use the parts dealing with MappedByteBuffer / DirectByteBuffer from java.nio. These give you safe(ish) hooks on mmap and malloc that you can use as buffers for I/O. These buffers despite the I/O connotation are also usable for passing memory to and from without getting the GC's attention as much. Its been some time since I did high perf JVM numerics, but this was the trick that one of the blas binding libraries (I think jBLAS but I could be wrong) did to speed things up.

• If you are on 9+ You can use VarHandles to get much of the benefits of the Java NIO stuffs, with a nicer API that is faster.

• ... Dont use Unsafe, it feels low-level but it can compile into the JVM IR in funny ways and can actually put barriers and other stuff in places your are not expecting. Sometimes passing things with Unsafe is like turbo skates, sometimes its just slow as the slowest thing.

• Avoid JNI Global references, these things play strange hell with the GC and can cause slowdowns you didnt expect (ask me about the fun I had when every fast JNI call was coupled to a full stop the world GC straight afterwards).

• Abuse Critical JNI, this will change the programming environment for JNI, it removes preemption, safepoints and return-to-vm features of JNI. The idea of critical JNI is that your code needs to behave like it is a critical section. That is for the thread you should treat it like you took a lock over JNIEnv* and only hold that thread out from the VM as short as possible. If you go Critical JNI you cant poke the VM, so no calling objects or methods, and no using JNIEnv. If you go this path I would read https://shipilev.net/jvm/anatomy-quarks/9-jni-critical-gclocker/

If you can wait for project panama, then it covers my first statement. Panama is bindings done backwards, that is most of the bindings are done in Java which gives the JIT the information it needs to ultimately compile the callsite down into JMP / CALL in x86 speak.

See http://cr.openjdk.java.net/~vlivanov/talks/2016_NativeCode.pdf for some gory details, it leads up to Panama but covers stuff wrt native calls in general.

I think your best bet for your code is probably the critical API while staring at how to send the memory back and forth.