Performance of JNI in VMKit

Dear developers,

Are there any benchmarks for the performance of Java Native Interface (JNI)
calls in VMKit? Since VMKit is based on LLVM which can also run C++ code
(maybe in the same just-in-time compiler?) I guess calls from Java to C++ and
back could be much faster than in Sun's JVM which has extremely slow C++ ->
Java callbacks.

If this was the case, this would be a big advantage of VMKit over all other
JVMs and mixing existing C/C++ libraries with Java would be as easy as in the
glue language Python.

All the best
  Bruno Daniel

Hi Bruno,

Dear developers,

Are there any benchmarks for the performance of Java Native Interface (JNI)
calls in VMKit? Since VMKit is based on LLVM which can also run C++ code
(maybe in the same just-in-time compiler?) I guess calls from Java to C++ and
back could be much faster than in Sun’s JVM which has extremely slow C++ →
Java callbacks.

If this was the case, this would be a big advantage of VMKit over all other
JVMs and mixing existing C/C++ libraries with Java would be as easy as in the
glue language Python.

While mixing C/C++/Java with the same compiler seems appealing for performance, Java has a garbage collector, and a garbage collector does not cope well with native frames. It requires object indirection when leaving Java boundaries, as well as being able to interrupt the execution of a thread for initiating a collection.

Note that it is possible to do it: VMKit is written in C/C++ and objects are being passed directly, and a C++ frame, since it is compiled by clang can be interrupted. However, it is very subtle how it works, and a slight omission of a GC object declaration leads to crashes that are hard to detect. It’s always possible to do better, like defining a convention that will tell clang which objects are being used by the GC, but it hasn’t been worked on yet.

If you don’t care about a GC, then sure, you can compiler C/C++/Java into a single native executable, where performance of inter-language calls are the same as intra-language calls.

Also, note that there were some works on trying to optimize JNI calls through inlining at runtime (http://dl.acm.org/citation.cfm?id=1064997). I don’t know if the optimization is actually being used in existing JVMs.

Hope this helps!
Nicolas

Hi Nicolas,

thanks for your detailed answer! Now I understand the issues a little better.
I'm going to install LLVM + Vmkit and try it out using JNI.

Regarding the garbage collector, do you think that the Garbage Collection ABI
of C++11 could be implemented in a way compatible to the JVM's garbage collector?
http://www2.research.att.com/~bs/C++0xFAQ.html#gc-abi

Perhaps this could make the C/C++/Java integration quite seamless and the
two worlds of the C-ABI languages and the JVM languages could be united.

All the best
  Bruno Daniel

Nicolas Geoffray wrote:

Hi Bruno,

Hi Nicolas,

thanks for your detailed answer! Now I understand the issues a little better.
I’m going to install LLVM + Vmkit and try it out using JNI.

Regarding the garbage collector, do you think that the Garbage Collection ABI
of C++11 could be implemented in a way compatible to the JVM’s garbage collector?
http://www2.research.att.com/~bs/C++0xFAQ.html#gc-abi

Hmm, isn’t that GC for C++ conservative? Ie treats integers whose value clash with an object pointer as a pointer to the heap? Then I would not use it… For sure it can be compatible, but it would hurt big time the performance of the JVM.

Nicolas