Beyond Java

GraalVM allows you to run Java, JavaScript, Ruby, and a broad range of other programming languages. They all run in the same virtual machine. So let's do the next logical step. Let's write a polyglot, multilingual application.

Traditional languages compiling to Java bytecode

If you're using a language like Scala, Kotlin, Groovy, or Ceylon, you don't need the GraalVM to write a multilingual application. These languages compile to Java bytecode, so there's a common denominator. In theory, nothing stops a - say - Scala class from calling a Java method or a Groovy method. This approach works well. Currently, I'm using a mixed setup of Java 11 and Kotlin at work.

World of languages. Image published at freesvg.org under a CC0 license by j4p4n

GraalVM doesn't change that. It just allows you to integrate many more languages running on Truffle. Languages like R, Ruby, JavaScript, and all those languages compiling to LLVM bitcode, and it promises to run them fast (or at least fast enough, as we've seen in the previous articles of this series). This article focuses on the non-bytecode languages and how they interoperate with Java.

Non-JVM languages aren't first-class citizens of Graal country

So I expected to be able to simply call a JavaScript function from Java, just as I'd call a method written in Kotlin. The JavaScript file is available in the project, so what stops GraalVM from running it?

To my disappointment, GraalVM doesn't work that way. Maybe there's simply no demand for this level of interoperability. Plus, you'd need a way to declare the JavaScript function to make them available to Java. In the case of Kotlin, that's easy: there's a pom.xml or build.gradle that links source codes from the two languages. At the end of the day, both Java and Kotlin files compile to bytecode, so calling one from the other is easy.

What polyglot programming looks and feels like

There's no such link between Java and the non-JVM language. So GraalVM uses a less ambitious approach. It provides an API you can use. The idea is you load the JavaScript file into a String and pass that String to Truffle. That's the same approach we already know from Nashorn and Rhino. Rhino is probably the better comparison because the API of Truffle resembles the API of Rhino.

Update March 07, 2021:

The disadvantage is there's no require statement. If you want to run a JavaScript application consisting of multiple files, you have to bundle it first with Webpack.

After some investigation, I finally found out that it's possible to use import statements. So your Java application can start a JavaScript application that uses other files. It's just that neither the GraalVM documentation nor most articles tell you how to do that yet. I've uploaded a working demo to my GraalVM demo repository on GitHub.

This is what a simple example looks like:

To execute a JavaScript file, you have to read it first into a string:

Calling JavaScript methods and passing parameters back and forth

Now the variable jsProgram contains a list of all global variables and methods. We can call the JavaScript method we've already used in the previous installment of this series:

Accessing the result is a bit tedious, but it's not a big deal. That's the tribute you pay to abstraction. The API of GraalVM has t work with any JavaScript application, so it uses very generic data types as return values. Everything a JavaScript function returns is a Value. That includes objects, methods, and functions. JavaScript programmers are used to this mental model, but if you've got a Java background, that probably comes as a surprise.

What about performance?

If we're to believe the official figures, the JavaScript performance of GraalVM is a lot better than the performance of the Rhino and Nashorn. We put that to the test. Spoiler: it's true. Mostly, that is.

We converted this example into a proper benchmark, pretty much the same way as we did in the previous part of this series. You can consult the source code at GitHub. The results were encouraging.

The performance is slightly worse than the performance of the pure JavaScript application. You know, we expected a performance penalty. The multilingual example sends the result to Java. The node.js example does not. The result is a huge array, consisting of 348513 numbers. So there's little to complain here.

To our surprise, the warm-up phase is less painful in the multilingual program than in the pure JavaScript application. We can only guess. When the Java application starts the JavaScript engine, GraalVM is already up and running, while the pure-JavaScript version starts cold. Whatever the reason is, it's a nice surprise.

Update March 07, 2021:

GraalVM CE 21.0.0 runs the demo a few percent faster. In particular, the start-up penalty has become a lot better.

A string-oriented benchmark

Number-crunching is all good and well, but it's precisely what you're not doing with JavaScript. During our research we stumbled upon a six years old article comparing Rhino and Nashorn, the older Java approaches to run JavaScript. This benchmark uses a JavaScript parser called esprima to tokenize the minified build of jQuery 3.5.1.

Of course, that's a far cry from being a scientific benchmark, but it has several interesting traits:

• it deals massively with strings
• it keeps the garbage collector busy
• it uses non-linear code execution (recursive-descent parsing).

Like always, we've published our benchmark on GitHub, so you run the benchmark yourself.

Benchmark results

On GraalVM 20.1.0, Truffle is the fastest engine, followed by Nashorn and Rhino. To our surprise, it's even faster than native node.js 12.4.1, at least in the long run. There's a severe cold start penalty. It takes GraalVM more than a hundred iterations to overtake node.js. The additional overhead of the Futamura projection shows.

Did I sell Truffle successfully to you? Well, I just compared the performance of the engines on the GraalVM. In the real world, you're probably using one of the good old standard JDKs. So I ran the benchmark again with AdoptOpenJDK 11.0.5. Of course, there's not Truffle. But in the long run, Nashorn almost reaches the performance of both node.js and Truffle.

We've also run the benchmark with AdoptOpenJDK 14.0.5. For some reason, Java 14 seems to be slower than Java 11. Maybe the LTS versions are heavily optimized, while development on the other version focuses on features. It's not the first time we've observed the performance penalty of Java 14. Newer is not always better. Putting it in IT terms: newer is not always faster.

Doing it the other way round

We've seen it's fairly easy to call a JavaScript function from Java, and we've also seen a pretty good performance, at least in the long run.

Here's the catch. Calling a Java method from a JavaScript (or Ruby, or R, or Python) is more cumbersome.

Come to think of it, that's no surprise except that we'd expect that from a virtual machine that claims to be polyglot. When we heard about it, we thought of a virtual machine that can use any combination of language, each interoperating with every other language.

As it turns out, we're using Truffle, the framework powering the polyglot features, to call methods in foreign languages. Truffle runs a wide variety of programming languages, but there's a huge class of languages not run by Truffle: the languages compiling to bytecode, such as Kotlin, Scala, Ceylon, Groovy, and Java itself.

Update March 07, 2021:

Recently Espresso made in into the official GraalVM release train. Espresso is a Java bytecode interpreter written with Truffle. So if you're ready to sacrifice some performance, you can now easily call Java code from every other language supported by Truffle. Currently, the Espresso team is working hard on improving the performance of Espresso, but it's unlikely it'll ever match the performance of the native Java implementation. On the other hand, if the primary language of your application is not Java, the performance of Espresso isn't important. Espresso opens opportunities you didn't have without it.

Cutting a long story short: Truffle enables a remarkable amount of interoperability, but it's not perfect. Java (run the tradional way, i.e. without Espresso) and the JVM languages get a special treatment in Truffle. Any Java object you want to use must be passed to Truffle. To do so, just call the method putMember() of the Truffle Context: