Comment by saurik | Hacker News Reader

Comment by saurik | Hacker News Reader

I have been paying some scant attention to GraalVM for some time, having been excited by "universal VMs" for decades now (including setups like LLVM, which most people forget was designed as a JIT-compiled VM, despite that being in the name), and I develop Cycript (which is somewhat the "opposite" technology, binding together existing virtual machines all into the same process space and doing crazy interop; though I haven't done a public release now in well over a year).

I am excited to see such a beast coming from a major company with a strong track record in VMs, and particularly given that it is based on their existing JDK, and am particularly excited that it now seems to be available!

I have some questions that I did not managed to easily get answered from looking over the website.

Can I AOT with this (via SubstrateVM) and deploy to "mobile" targets, and specifically iOS?

Are there any examples of embedding GraalVM in an existing native application (such as the noted idea of having GraalVM accessible inside of MySQL)?

Is there an existing embedding for node.js? (I don't mean "can I run node.js apps on GraalVM?"; I mean: from node.js, can I instantiate a GraalVM and give it code to execute in a new context, or will I need to build my own bindings to the GraalVM embedding API for that first?)

I did find some documentation for using an embedded GraalVM in a Java application, but while I work on many projects in many languages, none of them have been written in Java now for over a decade. I guess I was expecting a C/C++ API to be documented somewhere, not a Java API (due to the listed prototypical embeddings, and based on my long experience with embedding other virtual machines, including the Oracle/Sun JVM).

http://www.graalvm.org/docs/graalvm-as-a-platform/

Thank you for those questions.

> Can I AOT with this (via SubstrateVM) and deploy to "mobile" targets, and specifically iOS?

Technically there is no reason to not support it. But support is not implemented yet.

> Are there any examples of embedding GraalVM in an existing native application (such as the noted idea of having GraalVM accessible inside of MySQL)?

Yes. Oracle MLE[1] and MySQL already work. Oracle MLE you can try already. We have a native embedding API (its very similar to the Java API). We could not yet quite finish the documentation of it for website. But its already included look for a file polyglot_api.h in the binary.

[1] https://oracle.github.io/oracle-db-mle/releases/0.2.7/

> Are there any examples of embedding GraalVM in an existing native application (such as the noted idea of having GraalVM accessible inside of MySQL)?

The GraalVM in MySQL will be released soon and that will be the best example of embedding GraalVM in native projects.

The API for embedding in native applications is still experimental: it might change slightly in the few following versions. You can find the API with documentation in the polyglot_api.h file in the GraalVM distribution.

Is there an existing embedding for node.js

That's what their "node" program actually is. It's regular node but using GraalVM instead of V8. The semantic difference you're getting at doesn't seem to exist.

I guess I was expecting a C/C++ API to be documented somewhere, not a Java API

SubstrateVM has a C API that can be used to start it up that's not the same as JNI, however, bear in mind Graal can be used as a plugin to regular HotSpot too. So you can just embed the JVM the usual way and ship the Graal compiler with it, enabled via a command line flag. So yes you can do this and it doesn't require any new documentation.

> That's what their "node" program actually is. It's regular node but using GraalVM instead of V8. The semantic difference you're getting at doesn't seem to exist.

No, because what I'm trying to accomplish is "I'm inside of a node.js program and I want to instantiate a GraalVM virtual machine instance context, load a random Java class (or whatever), and run a function on that class". Even if I'm running my node.js code on top of GraalVM, the semantic difference fundamentally exists. Like, you are trying to tell me that somehow running my node.js program on top of GraalVM is the same thing as being able to run GraalVM from inside of my program (which just so happens to be written in node.js, but that's arbitrary and meaningless in a way: I just want good bindings for the language I happened to write it in) on arbitrary code, but that clearly doesn't make any sense. I mean, it certainly isn't true for their Java embedding API, why/how would it somehow be true for their node.js API?

> SubstrateVM has a C API that can be used to start it up that's not the same as JNI... So you can just embed the JVM the usual way and ship the Graal compiler with it...

But SubstrateVM is the offline VM for AOT use, not the runtime VM for JIT use, so I really am not that interested in the SubstrateVM API... it isn't at all relevant for the use case I'm describing for embedding GraalVM; and the Graal compiler in this context is also for AOT use, which again isn't relevant for the use case of embedding the GraalVM.

What makes GraalVM interesting here is that it is a JIT. Just take a step back for a second and imagine you have a C program, and you want to boot that JIT and use it, as a library, loaded into your process. That's the use case here. You seem to be confusing that with either running the C program inside of the VM (which doesn't even change the problem) and then later with pre-compiling the thing we want to load and bringing the compiled code into the process (which bypasses the wonderful goal of working with the JIT).

The way you do this using their Java embedding API is clearly documented, and it is absolutely not the same thing as running a Java application in the GraalVM: it is a set of APIs that let you instantiate Graal Context objects, eval() code in various languages, and then work with the proxy Value objects. I am asking if that API has been exposed to any languages other than Java yet. It seems (from the answer from someone who actually works on Graal from 8 hours before your comment) that the answer is "yes" for C/C++, but I'm still guessing the answer is "no" for node.js.

http://www.graalvm.org/docs/graalvm-as-a-platform/embed/

My point is that you can load GraalVM into an already running process using JNI and access objects that way. JNI isn't a great API by any means but it works and there are tools to bind to it. It isn't new and I don't think GraalVM without Substrate or Sulong innovates in this area.

So if you wanted to run JavaScript using GraalJS, from C, you would link against libjvm, use JNI to initialise the VM with Graal as the JIT compiler (there's a special flag for this), and then use the Polyglot API via JNI.

To bind from JavaScript to Polyglot without having Graal be the host would presumably require you to write a V8 extension that then loads the JVM using JNI and proxies back and forth. I think there are projects that do this already. But you wouldn't get the performance or convenience improvements than Graal/Truffle are pioneering.

In the end though, embedding the JVM this way - at least for node apps - would not be better or more efficient than using their node implementation, but ignoring things like performance and debuggability the results are presumably identical unless your code depends on an implementation detail of V8. So I don't get why you'd do that.

> you can just embed the JVM the usual way and ship the Graal compiler with it

How feasible would it then be to use Graal NFI for FFI from vanilla Java? That seems useful given the performance limits of JNA and the complexity of JNI.

Reply on news.ycombinator.com