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, On Wed, Jun 20, 2012 at 3:04 PM, Bruno Daniel <abml at mailoo.org> wrote:> 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> > All the best > Bruno Daniel > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120623/950a857d/attachment.html>
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, > > On Wed, Jun 20, 2012 at 3:04 PM, Bruno Daniel <abml at mailoo.org> wrote: > >> 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 > > >> >> All the best >> Bruno Daniel >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>