[LLVMdev] Performance of JNI in VMKit
nicolas.geoffray at gmail.com
Mon Sep 3 12:33:59 PDT 2012
On Wed, Jun 27, 2012 at 10:58 AM, Bruno Daniel <abml at mailoo.org> wrote:
> Hi Nicolas,
> thanks for your detailed answer! Now I understand the issues a little
> I'm going to install LLVM + Vmkit and try it out using JNI.
> Regarding the garbage collector, do you think that the Garbage Collection
> of C++11 could be implemented in a way compatible to the JVM's garbage
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.
> 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
> >> 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
> >> 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
> >> JVMs and mixing existing C/C++ libraries with Java would be as easy as
> >> 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
> > 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
> > will tell clang which objects are being used by the GC, but it hasn't
> > 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
> > 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).
> > 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...
More information about the llvm-dev