If you read press around Java you’ll have come across references to GraalVM. So what is it and why would I use it?

There is an excellent podcast from Software Engineering Daily that digs into the subject and can be found here and here. But let draw out some of the reasons as to why GraalVM is interesting.

Whilst multiple languages on top of the JVM is nothing new, such as Scala , Kotlin, and Groovy to name a few, GraalVM through the use of its Truffle framework takes it a new level. Truffle provides an Abstract Syntax Tree (AST) which describes the language syntax (more here about AST). The net result is any language can be described and therefore executed using the GraalVM. To this end the GraalVM team have got Node and JavaScript ported in addition to defining existing languages using this approach. Not all of this is proven robustly in production, but some of the languages VM certainly is, for example Twitter have been using the Scala port.

Because the languages are described through the same framework this means the work to optimise the VM performance becomes a lot easier.

It would be easy to assume that using the framework would mean the execution of languages using this mechanism would slow be slower. But, Truffle works by translating the code to standard byte code before execution, so ‘ported’ languages are now no less efficient than Java come runtime.

There is an interesting bi-product of this model, that at runtime with the right object exposures it is possible for multiple languages to interact with the same object easily, no JNI or dropping to the lowest common denominator such as a JSON+REST. This does raise interesting possibilities for thick client solutions or polyglot monoliths!

Probably one of the biggest pay offs for using GraalVM and its ability to run multiple languages is that the base Container images can be simplified as you don’t need different container images. This makes the work of patching and testing configurations of these container a lot simpler as the permutations will drop, particularly for organisations that have wholehearted embraced polyglot micro-service ideas.

One common reason for changing implementations of the JVM particularly at the more performance sensitive use cases (checkout Azul as an example) is how the JVM is optimised and the JIT algorithms and processes particularly the Garbage Collector work (checkout this list of JVMs. For example GraalVM will provide better performance for processes that less heap hungry than Oracle’s JVM.

It is interesting that Oracle are investing in a new VM when it wasn’t that long ago that JRockit was wound down. Given the legal dispute between Oracle and Google (see here) the new VM would give Google a means to escape from the copyright breaches and retain support for Java.