[LLVMdev] Performance of JNI in VMKit

Nicolas Geoffray nicolas.geoffray at gmail.com
Mon Sep 3 12:33:59 PDT 2012


Hi Bruno,

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
> 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


>
> 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
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120903/68723911/attachment.html>


More information about the llvm-dev mailing list