Right now, maven central has 2 of 4 jars needed to run graal.js on non-graalvm jdks. Graal-sdk, and truffle api. Tregex and graal.js.jar should me published to maven central as well so people can start testing running the polyglot engine and graal.js on non-graal vm jdks. I've tested this setup works by ripping the graal.js and tregex from a graalvm ce 1.0.0-rc2 release and putting them on the classpath with the graal-sdk and truffle api jars.
Hi Mark,
we are a bit careful with that approach. Yes, it does work - but we do not recommend it, as performance is far off of what you get when running on GraalVM itself. This problem might be resolved in future versions of JVM; we are working with the Oracle JVM team so that future JVM versions will have the relevant support built-in already, and you just need the respective .jar file of the language you want to use.
We'll discuss internally how to better distribute until then.
Just to add another data point here, there are definitely users out there who don't care that much about performance or AOT and would just like access to all the convenient interop stuff on a stock JVM.
(Also I've been struggling to find information about what the differences actually are between GraalVM and the JVM. Graal can be used as the JIT compiler on a normal JVM via JVMCI, right? I'm confused as to what else is involved that means the performance is still "far off" from the GraalVM, is there any documentation which goes over this?)
The version of Graal in the stock JDK does not (currently) include Truffle partial evaluation. For example:
> jar tf /Library/Java/JavaVirtualMachines/graalvm-ee-1.0.0-rc2/Contents/Home/jre/lib/jvmci/graal.jar | grep truffle | wc -l
256
> /Library/Java/JavaVirtualMachines/jdk-10.jdk/Contents/Home/bin/jmod list /Library/Java/JavaVirtualMachines/jdk-10.jdk/Contents/Home/jmods/jdk.internal.vm.compiler.jmod | grep truffle | wc -l
0
Ah I understand, thanks.
+1 for this functionality 馃挴
we are a bit careful with that approach. Yes, it does work - but we do not recommend it, as performance is far off of what you get when running on GraalVM itself. This problem might be resolved in future versions of JVM; we are working with the Oracle JVM team so that future JVM versions will have the relevant support built-in already, and you just need the respective .jar file of the language you want to use.
We'll discuss internally how to better distribute until then.
Are there any metrics available on performance without GraalVM? Is it better/same/worse than Nashorn is probably the key one...
Does any of this (running GraalJS on a normal JDK) change with Java 11?
I'm interested in GraalJS as an upgrade for Nashorn - given it's deprecated any never going to get ES6+/Node.js features.
@jonnermut without Graal (Graal, the Java JIT compiler), there is no special optimization of the Graal JavaScript interpreter. No partial evaluation (as with Graal), no bytecode generation (as with Nashorn). Performance characteristics are those of an interpreter than, definitly worse on peak performance.
On JDK11+ it will be possible to execute Graal.js with Graal as JIT compiler by setting a few JVM flags. Performance will then be identical to using our custom-built GraalVM.
Thanks for the explanation @wirthi
Is there any doco yet on how to use Graal.js with JDK 11? We'll still need to manually add the Graal.js jar and its dependencies?
+1 for tregex, graaljs and graaljs-scriptengine
On JDK11+ it will be possible to execute Graal.js with Graal as JIT compiler by setting a few JVM flags
@wirthi what are the JVM flags to set?.
We are trying Graal.js with http://jdk.java.net/11 (macos) but is running in interpreter mode.
I'm with @eliasvasylenko - I'm interested in running JavaScript on a JVM, regardless of performance.
At the moment we're just interested in evaluating Graal as an alternative to Nashorn for our existing Java application that runs JavaScript extensions.
Is it just a matter of getting the two missing jars (which aren't published to Maven Central?) and adding them to the classpath?
If that's the case, and if performance becomes a concern, we could look at using the Graal JIT compiler as a future option.
In case it helps anyone else, here's what I did that got me off the ground:
jre/tools/regex/tregex.jar and jre/languages/js/graaljs.jar from the download to the classpath of a Maven projecttruffle-api and graal-sdk as Maven dependencies (same version as the downloaded SDK)org.graalvm.polyglot.Context and related Java APIsI don't know if that's complete, but it's sufficient to run a trivial JavaScript on a JVM from a Java program, with performance caveats per above.
We plan to publish all the necessary artifacts for running on JDK 11 (with additional JVM flags) to Maven Central in the near future. Stay tuned.
We plan to publish all the necessary artifacts for running on JDK 11 (with additional JVM flags) to Maven Central in the near future. Stay tuned.
Hi Andreas, I wonder is there any updates on publishing? Is there some ETA when this is going to be done? Thank you very much!
@zzFluke the artifacts are already in maven central, the rc8 release notes have instructions on how to use them: https://www.graalvm.org/docs/release-notes/#10-rc8
See also this example project: https://github.com/graalvm/graal-js-jdk11-maven-demo
Many thanks @rsalvador !!! I'm going to give it a try.
Edit: See https://github.com/graalvm/graaljs/issues/17#issuecomment-466366664 for official benchmarks, the measurements below were done on an old laptop running other software just to get a general idea, so they are probably not very accurate.
For future reference, to set some very rough performance expectations:
Running the example project with graal.js version 1.0.0-rc12 on openjdk 11.0.2 with a dated Intel i5-3210M (4) @ 3.100GHz: Without adding command line flags, graal.js is ~5x slower than Nashorn.
Adding command line flags makes it ~3x faster than Nashorn. Using ScriptEngine vs Context did not have a huge impact.
For future reference, to set some very rough performance expectations:
Running the example project with graal.js version 1.0.0-rc12 on openjdk 11.0.2 with a dated Intel i5-3210M (4) @ 3.100GHz: Without adding command line flags, graal.js is ~5x slower than Nashorn.
Adding command line flags makes it ~3x faster than Nashorn. UsingScriptEnginevsContextdid not have a huge impact.
@zimmi, may I wonder which flags did you mean?
@zzFluke
I ran mvn clean package inside the example project, which runs all benchmarks. Looking at the pom.xml, this adds the following flags: -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI --module-path=${compiler.dir} --upgrade-module-path=${compiler.dir}/compiler.jar. To run the benchmarks without the flags, I just commented out that section in the pom.
${compiler.dir} contains org.graalvm.compiler:compiler, org.graalvm.truffle:truffle-api and org.graalvm.sdk:graal-sdk.
Hi @zimmi, Hi @zzFluke
thanks for your investigations. We have just published a blog post to bring more clarity into this and present it more officially.
https://medium.com/graalvm/graalvms-javascript-engine-on-jdk11-with-high-performance-3e79f968a819
Thanks,
Christian
I'm trying to create a ScriptEngine with "graal.js" however, I always get null (see reference above). Any hints what might be wrong?
EDIT: Nevermind, I think I've messed up my Maven dependencies...
Hi @plata
what setup are you using? Do you start from JDK11 as in the blogpost, or are you on one of our GraalVM builds? On GraalVM, I don't see any obvious reason why that should not work (if so, can you please post a minimal example of your code and commands to start). On JDK11 or any other setup where you provide the JARs yourself, the most obvious thing missing could be the jars for js-scriptengine. If you start from our demo application (https://github.com/graalvm/graal-js-jdk11-maven-demo) as described in the blogpost, that should not happen. Again, if this still fails, please post your source code and command lines, then we might be able to help you.
Thanks,
Christian
Like I said, I've found my error in the meantime (I had added the dependencies to dependenyManagement in Maven...). Nevertheless, thanks for your response.
Most helpful comment
We plan to publish all the necessary artifacts for running on JDK 11 (with additional JVM flags) to Maven Central in the near future. Stay tuned.