The evolution of Java to become a vendor neutral platform, move to a six month release cadence and the platform advancements in last releases are more than welcome. As a community, we witness an interesting transformation of the Java platform — from a pretty steady platform that used to release new features every 2 years (i.e. see Java 7 & Java 8 release dates) into a platform that is moving fast and have to compete with the new players in town that evolve rapidly. From my perspective, its really interesting to read the debate and see how enterprises will adopt these rapid innovations after a really long time that they got used to the tradeoff of having stability in favour of innovation and unpredictable changes.
Despite the great advancements that Java 9 brought with its release last year (i.e. Modularity — Project Jigsaw), I think there wasn’t much buzz around two really interesting JEPs — JEP 243 and JEP 295. Both bring with them new awesome capabilities that can take the Java platform several steps ahead of the other platforms!
What if you could have a universal VM?
GraalVM is a research project developed by Oracle Labs and already in production at Twitter and they even contribute back to the project which is awesome (see this JavaOne talk by Christian Thalinger on why Graal is a good fit for Twitter). Graal is a JIT (Just-in-time) compiler that can be plugged-in to the Hotspot VM. JIT is basically the component that translates the JVM bytecode (generated by your javac command) into machine code which is the language that your underlying execution environment (i.e. your processor) can understand — and all that happens dynamically at runtime! Graal aims to replace the old C2 compiler that is written in C++. Leading contributors in the Java community say clearly that it became a hard task to maintain the existing compilers code. GraalVM is appealing because finally you can debug the JIT compiler right in your standard development environment that you use daily since its written in Java and its much easier for developers to dive in.
So how come we can have another JIT compiler that can be plugged-in and even written in Java?!
Why am I so enthusiastic about GraalVM?
Im using GraalVM 1.0 (based on JDK 8). Lets compile and run:
java -cp . SumNum
It prints the result: 3
I’m curious to see what happens in case of a runtime exception- instead of calling parseInt I will call some undefined function:
Obviously, interoperability in Graal is a tradeoff between selecting the best language for my task vs. static code analysis at compile time.
Language agnostic tools — All languages talk to the Truffle framework except Java & Scala. So you can use the same set of tools for monitoring, debugging and profiling. Awesome! It makes development experience much easier in terms of performance. Currently, the way that Graal implemented it is quite limited. They are integrated with the Chrome Dev Tools protocol. It’s very easy to debug your running VM. All you need to do is run your script with the inspect argument, it will open a port and you can debug using the Chrome Dev Tools any language that you want to : R, Python, etc. Check out their documentation for more information.
Something that caught my eyes in one of the talks by Oracle was how Chris used the jvisualvm tool to profile a Ruby application and he could even take a Thread dump. Cool, isn’t it?! ;)
It just shows how powerful it is to have a one abstract platform. Now all you have to do is close your eyes and dream of the great things that can happen with such great capabilities.
Performance — Graal benchmark reports show great performance improvements in almost all of its implementations thanks to the way that GraalVM performs object allocations:
Thomas mentioned that they see great improvements for Java Streams, lambdas and their recent benchmarks even show better numbers for various implementations. Chris Seaton blogged that “TruffleRuby is easily the fastest implementation of Ruby, often 10x faster than other implementations, while still implementing almost all of the language and standard library”. Twitter is running GraalVM in production especially because of its performance improvements in their Scala services. They say that it saved them money.
In terms of interoperability, Thomas showed in his talk at Devoxx the advantages of calling one language to another in the same process. The benchmarks show clearly that you can cut the costs of context switching and objects marshalling/unmarshalling:
One more interesting project that is part of GraalVM is the Substrate VM. I include it as part of the “performance” section but it’s more ambitious than that. The Substrate VM is an AOT (Ahead-of-time) compiler (see JEP 295 — the integrated AOT compiler in JDK 9 is older and I’m not sure what’s integrated in JDK 10 and JDK 11) written in Java. It uses GraalVM to create an executable binary Mach-O or ELF image ahead of time that doesn’t need to run on the Hotspot VM but rather in the Substrate VM itself. It takes some time to compile but at the end you have an executable binary that you can run anywhere you want: server, mobile device, etc. The cool thing here is that it performs all the optimisations and packaging ahead of time so the resulting image startup time is much faster (according to their documentation you will have much lower runtime memory overhead because it performs all of the optimisations at compile time):
As you can see in the screenshot above, it took more than 2 minutes to compile my sample polyglot program but its execution time is much faster (check out GraalVM reference for benchmarks). As far as I understand there are various limitations but the first advantage that immediately came up to my mind is that as my system scale I can spin up new containers much faster than before. I came across this blog post that explains how you can create an instant Netty startup image;)So just imagine how many great things you can do with that.
It looks like Oracle moves in the right direction in order to take the JVM platform forward. Graal becomes more integrated in JDK 10 according to JEP 317. Now it becomes even simpler to change between compilers just by adding several command line options. If you aren’t using JDK 10, you can download one of the editions (at the time of writing GraalVM 1.0 is based on JDK 8) from the GraalVM website and packaged already with the other languages runtimes so you can experiment the polyglot programming easily.
I hope that you have enough information to help you get started. I hope that Oracle will continue to invest time in this great project.