GraalVM: the holy graal of polyglot JVM ?, Hacker News

Transposit is built on a Java backend uses Nashorn. We wanted to support ES6 syntax, so we investigated alternatives.

Sarah Brown · Jan 2, 2019

Transposit is built on a Java backend and runs customers ’JavaScript on the server-side usingNashorn. After our recent alpha launch, we received numerous customer requests to support ES6 syntax.Nashorn is deprecated in JDK 11and so is unlikely to ever support full ES6 syntax, so we began investigating alternatives – andGraalVMis where we landed.

Why GraalVM?

GraalVM isOracle’s recommended replacement for Nashorn, despite the technology being relatively new. We liked the idea of a more performant compiler, and we’re interested in potentially using the GraalVM to allow customers to script inother languages like Python or Ruby besides our currently supported languages (JS, SQL).

We considered introducing NodeJS into our stack, but decided it would take more time and effort than we wanted to invest just to be able to use ES6 syntax. So we chose GraalVM instead because the migration path from Nashorn is clear and fast.

As easy as advertised?

While some things were well documented (such asNashorn compatibility mode), adopting such a new technology unsurprisingly had areas that lacked documentation and included a few hurdles to jump. We want to share with you all some lessons learned from our adventure.

GraalVM is a collection of many projects, not all of which need to be used at the same time. In the case of migrating from Nashorn to GraalVM, we used:

Truffle: A Java library for building language implementations.
GraalJS: The JavaScript language built using Truffle.
GraalVM Polyglot API: The API that enables the embedding of Truffle languages (the guest language) within the JVM (the host language).
Graal Compiler: A JIT Java compiler that shows impressive performance benefits generally, and specifically it provides optimized performance for Truffle-based languages running on the JVM.

One of the most popular GraalVM features iscompiling JVM programs to native. This feature is great for those who need smaller executables or faster startup times, butpassing Java objects to Graal languages is not currently supported by native. Fortunately, the performance improvements gained by compiling to native isn’t an immediate need of ours.

Running GraalJS on JDK 8, JDK 11, and beyond

In more recent release candidates, the Graal folks have published Truffle and GraalJS jars. This is great news for those not yet on JDK 11: it means we can still use GraalJS, just with the downside thatJavaScript will be interpreted instead of optimizedvia the Graal Compiler. Just include the following maven dependencies to get started:

  org.graalvm.sdk  graal-sdk  1.0.0-rc8  org.graalvm.truffle  truffle-api  1.0.0-rc8  org.graalvm.js  JS  1.0.0-rc8

For those on JDK 11, you can run the Graal Compiler using the following flags:

- XX:   UnlockExperimentalVMOptions -XX:   UseJVMCICompiler

You can also use the Graal Compiler bydownloading it directly. If you go this route, Truffle and GraalJS are included by default, and so you only need to explicitly add the SDK:

  org.graalvm.sdk  graal-sdk  1.0.0-rc8

Migration gotchas

Reading from multiple threads

With Nashorn we’d been caching our ScriptObjectMirror objects for parallel runs of the same function. We found thatGraalJS disallows reads from the same Context across threads. As a result we’ve stopped caching across threads.

Closing Context

Now that we no longer cache Contexts, we have to remember toclose each Contextonce we’re done with it:

if the context is no longer needed, it is necessary to close it to ensure that all resources are freed. Contexts are also AutoCloseable for use with the Java try-with-resources statement.

Listing languages in META-INF

The Graal SDK looks for languages to use underMETA-INF / truffle / language. The published GraalJS library comes with its own list of languages, but 1.0.0-rc8 and rc9 don’t include the regex language that it’s dependent upon. For the moment, we wrote our owntruffle / language (file:)


language1.characterMimeType.0=application / tregex language1.className=com.oracle.truffle.regex.RegexLanguage language1.id=regex language1.implementationName=language1.interactive=true language1.internal=true language1.name=REGEX language1.version=0.1 language2.className=com.oracle.truffle.js.parser.JavaScriptLanguage language2.dependentLanguage.0=regex language2.id=js language2.implementationName=language2.interactive=true language2.internal=false language2.mimeType.0=application / javascript language2.mimeType.1=text / javascript language2.name=JavaScript language2.version=1.0
PolyglotBindings vs. Bindings#
Most of theexamples in the GraalVM documentationusecontext.getPolyglotBindings (). However, polyglot bindings require an import statement in the JS, so we usecontext.getBindings ("js")instead.
(CommonJS modules) #
Nashorn does not provide the CommonJSrequire ()syntax and unfortunately neither does GraalJS. There's a popular solution for Nashorn callednashorn-commonjs-modules. Graal tooling is less evolved, so we createdour own commonjs forkfor our Graal solution.
(Conclusion) #
While most of the hype around GraalVM has been around compiling JVM projects to native, we found plenty of value in its Polyglot APIs.GraalVM is a compelling and already fully useable alternative to Nashorn, though the migration path is still a little rocky, mostly due to a lack of documentation. Hopefully this post helps others find their way off of Nashorn and on to the holy graal.