If you read press around Java you’ll have come across references to GraalVM. So what is it and why would I use it?
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.