[graalvm-users] Fwd: GraalVM to extend a native framework

[Roland Schatz]

Hi Dmitry!

Thanks for your interest in GraalVM. Answers are inline below.


On 3 May 2018 at 15:40:08, Dmitry Timofeev (dmytro.tymofeev at bitfury.com 
<mailto:dmytro.tymofeev at bitfury.com>) wrote:
>
> Hi,
>
> I’m working on making a framework in a native language (Rust) 
> extensible in other languages (Java, Python). We currently use JNI, 
> which is low-level and error-prone. I consider if GraalVM would make 
> some things easier or make the integration more efficient. Would 
> anyone please help with these questions?
>
> 1. Is it a good use-case for GraalVM? It seems so from the docs, as 
> GraalVM aims to eliminate the costs associated with calling code 
> running on a VM from the native code and vice-versa.
>
Yes, this is a perfect use-case for GraalVM.

Since Rust compiles to LLVM bitcode, you should be able to run your Rust 
code using the LLVM support in GraalVM. But be aware that Rust support 
is still experimental. We do most of our testing with C/C++, only very 
basic testing is done for Rust, so you'll likely run into a few bugs, 
but we're happy to help if you run into problems.

> 2. The reference documentation says C --> Java is not supported yet, 
> but coming soon.
>
>
Support for C->Java interop (actually LLVM->Java interop) just landed in 
master (see 
https://github.com/graalvm/sulong/commit/a8ec4a7e8cb4488c7f8b774bbc7b1342efd92c71 
), and will be included in RC2.

> Does it mean that developers will be able to use Java from C with /no/ 
> JNI (= pass arbitrary structs, call any Java method from any native 
> thread)? Is it going to be a viable full-featured replacement for any 
> JNI use-case?
>
>
Note that our LLVM->Java interface is different from usual native 
interfaces, since running LLVM code in GraalVM is not actually running 
native code, it is running the LLVM code inside the managed VM (but 
still accessing native memory). Because of that, it's not directly 
comparable to JNI. With JNI, you're basically "leaving" the VM when you 
call a native method. With LLVM on GraalVM, you're running your 
C/C++/Rust code inside the VM.

The LLVM->Java interface is very similar to all other LLVM->* interop 
interfaces we have in GraalVM (see 
http://www.graalvm.org/docs/reference-manual/languages/llvm/#interoperability 
and http://www.graalvm.org/docs/reference-manual/polyglot/).
You can just load Java classes and use them using the regular polyglot 
builtin functions. You can pass native structs and access them from Java 
directly, and you can "cast" Java objects to native structs and access 
them as if they were real native memory. All of this works without any 
data copying. This is one of the main advantages of our polyglot 
execution model. And all of that works not just with Java objects, but 
also with all other languages that run on GraalVM (e.g. Javascript). As 
such, this is much more flexible than JNI.

> 3. If I do such integration of a native language with Java the old way 
> — using JNI, native methods and libraries — but run on GraalVM, will 
> this application enjoy any inter-language optimizations?
>
>
No, the compiler can not optimize across JNI calls. You will of course 
still get all optimizations between the individual GraalVM languages 
when they call each other and exchange data, but every transition 
from/to native code will be an optimization boundary for the compiler.


I hope this answers your questions. Your project sounds very 
interesting, I encourage you to play around with that, and report any 
problems you encounter.

- Roland

> Thanks!
>
> --
> Dmitry
>
> -- THIS COMMUNICATION AND ANY ATTACHMENTS MAY CONTAIN CONFIDENTIAL 
> INFORMATION OF THE SENDER. ALL UNAUTHORIZED USE, DISCLOSURE OR 
> DISTRIBUTION IS PROHIBITED. IF YOU ARE NOT THE INTENDED RECIPIENT, 
> PLEASE NOTIFY THE SENDER IMMEDIATELY AND DESTROY ALL COPIES OF THIS 
> COMMUNICATION. THANK YOU.
> _______________________________________________
> GraalVM-Users mailing list
> GraalVM-Users at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/graalvm-users


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.oracle.com/pipermail/graalvm-users/attachments/20180509/eaeff53b/attachment.html