llvm dev - Jun 2012 - [LLVMdev] 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,

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