Why I am excited about GraalVM

For some time now I am very excited about this “new” project called GraalVM. Even now as I am writing these lines I cannot control my excitement. Let me share with my excitement about this new and revolutionary technology which takes single languages to something beyond. As single quote to show you my meaning:

“One ring to rule them all,
one ring to find them,
One ring to bring them all and
in the darkness bind them.” (J. R. R. Tolkien)

Introduction to GraalVM

For those who are yet unfamiliar with this project, GraalVM is a universal virtual machine for running applications written in JavaScript, Python, Ruby, R, JVM-based languages like Java, Scala, Kotlin, Clojure, and LLVM-based languages such as C and C++. (Taken straight from their web page). Basically what this means is that it is a High-performance polyglot Virtual Machine.

Under the Hood in a flash

GraalVM is a product from Oracle Labs. It is a native code generator which is written entirely in Java (yes, Java. With a capital “J”). Already with Java 10 GraalVM has been introduced as an experimental feature in the JDK as the C2 JIT compiler replacement.

GraalVM, just like the C2 JIT compiler translates bytecode into machine code. What makes these JIT compilers so great is their ability for optimizing the code., and GraalVM even more so.

Support for non JVM based languages is available by way of the Truffle framework. This framework enables one to build interpreters and implementations for other languages besides Java & Scala. It is being done by translating any language into an Abstract syntax tree (AST) which then the Graal Compiler can turn into bytecode and the rest is history.

Why do I need this ?

OK, but what do I care, and especially, why do I need that ? Each language comes with its runtime ! What is so exciting about a runtime environment which knows to run any language (really…?).

The Bigger Picture

True, each language comes with its runtime, but you are missing the bigger picture here. As more and more languages are being used in a polyglot attitude having a “multi runtime environment” might not be such a bad idea. Even in the docker era, instead of having many different dockerfiles and containers we could have just… one ?!

I’ll leave you to ponder on this for a minute… Furthermore, the many possibilities and abilities of having such a unified platform are mind boggeling. So let me share with you my top 3 Favorite GraalVM abilities

My top 3 Favorite GraalVM abilities

Superfast

Yes, it is true. GraalVM is superfast. It is also one of their mission goals: “Our vision was to create a single VM that would provide high performance for all programming languages” This is being achieved by the very aggressive optimizations, for any language as the GraalVM is language agnostic.

But don’t just take my word for it, ask Twitter who is using GraalVM in production for some time now enjoying the performance boost. They are hardly the only ones. All over the net you can find POCs and benchmarks showing just how big the performance improvement is for example the following improvement using the streams API

Not only JVM languages receive a performance boost but other languages as well. The biggest beneficiaries of this performance boost are less used languages. Those languages never gained enough traction to deserve/need a faster runtime. Such languages include Ruby, R and even Python (not shown in the graph)

Please note, not all languages receive a performance boost (yet ?). Work is still underway and the mission statement still applies. Personally I witnessed a JavaScript app which ran 25% faster on the GraalVM JavaScript Engine than on V8. Needless to say, performances vary depending on what your application does.

Multi language interoperability

Pause! Let that sink it. This is incredible.

import org.graalvm.polyglot.*;
import org.graalvm.polyglot.proxy.*;

public class HelloPolyglot {
	public static void main(String[] args) {
    	System.out.println("Hello Java!");
    	Context context = Context.newBuilder().allowAllAccess(true).build();
    	context.eval("R", "print('Hello R!');");
	}
}

I do not know if you fully comprehend what has just happened here in front of your eyes. I am running a function in “R” from within Java in this example. I can even share objects, pass values or objects as values to functions and use the return values. Gone are the days of JNI. Enter the new world of multi language support. This is on a whole new level.

Precompiled Java Images

For me this is the pièce de la résistance.

It is a bit odd to speak about Java in “native” terms, but it is not unfamiliar. Already in Java 9 we received “jlink” which allows us to assemble a set of modules and their dependencies into a custom runtime image. Jlink would insert part of the compilation environment JRE into the resulting assembled package. This means it is platform dependant. GraalVM on the other hand insert a virtual machine (SubstrateVM) into the assembled plackage, making the runtime image platform independant !

Following is a list of some of the huge benefits of precompiled java images:

  1. An order of magnitude startup times on JVM startup (it can got to a few milliseconds)
  2. Smaller memory footprint
  3. Smaller runtime environment footprint (including the JVM drop itself)

More and more do I see implementations and use cases of this such as this one for vert.x which rendered a 27MB Native image (!). And this image is not patform dependant either. It can be run on any environment as it contains a VM. Coming from the Java world, this is truly magical.

Not everything is perfect and this feature has some serious limitations as of now, but I am confident that some will be sorted, others will be worked around and the rest will be an interesting challenge.

Conclusion

Hopefully I was able to convey to you my immense excitement about this project and infect you with some of my enthusiasm about the exciting new abilities this project brings into the world of programming

Backend Architect & Tech Lead

Backend Group
Thank you for your interest!

We will contact you as soon as possible.

Send us a message

Oops, something went wrong
Please try again or contact us by email at info@tikalk.com