Why GraalVM is currently one of the hottest Java topics
In 2013, Oracle labs came with a scientific article named “One VM to Rule Them All”. In this article they described a generic Virtual Machine (VM) that could be used to run any programming language, as long as it implements a specific language interpreter for the “one VM”. As described in the article, plotting a language on such a VM comes with several benefits. First of all, once the language has been plotted to the VM it can run on any system on which the VM itself can run. The VM will translate the code written in the language to code that the actual machine can run (machine code). Just like your good old Java Virtual Machine. With the added benefit that it can run more than one language.
The second benefit is that any language that runs on the VM benefits from the optimization that is being done in the VM. During the translation of code to machine-code, the VM can execute optimizations. In the past we have seen that this can result in significant performance increase. Just look at the JVM: the main reason for the good performance of Java is the optimization layer within the JVM. Normally optimizing your language is very complex and time consuming, thus expensive. With the proposed solution, from the paper, it would be a matter of making sure that the language can run on the VM. The added benefit is that the interpreter you have to write for this, allows you to create your custom optimization.
Last but not least, because you can run multiple languages on the same VM you can create Polyglot applications that use libraries from multiple languages interchangeable. Now this all looks well and promising and the article indicates that they have a working prototype. But when can I use it?
Fast forward to the now (2019) and you can download the actual implementation of the “One VM” GraalVM (1.0.0rc15 when I typed this). In this article (and some blog posts) we (Thomas Janssen and I) will take a deep dive into GraalVM and see if it can meet the promises of the article and why it is one of the hottest topics in the Java world atm.
Looking at GraalVM you will notice that is consists out of several projects / components. Some are interesting for application developers and some are interesting for language developers. We will zoom in onto the components that are the most interesting according to us (application developers)
- Graal (JIT) Compiler
- Substrate VM (Ahead of Time compilation)
- Graal SDK
“Truffle is an Open Source library for building programming language implementations as interpreters for self-modifying Abstract Syntax Trees.”
Truffle is a framework (API and DSL) that can be used to create a language specific interpreter that compiles your application code to one or more Abstract Syntax Tree(s) (wikipedia). An AST is an interpretation of all the possible actions (nodes) that can run when execution your code. These ASTs then run on the GraalVM and are executed eventually as actual machine code.
The reason why this is interesting, is because when you have your own language and you want to run it on a VM like graal, you only have to create your language interpreter using the Truffle framework. Once you have done this, you can run your language on the GraalVM. It also allows you to provide the VM with further instruction when it is optimizing the machine code. A nice presentation from Jackie Haynes from Goldman Sachs shows the possibility of Truffle when you have your own language (slang).
When Truffle is the interpreter that creates the ASTs, Graal is the Just in Time compiler that compiles the AST into machine code. Using Truffle in combination with Graal means that your language is interpreted by truffle and optimized by Graal and that it runs on the Java Hotspot JVM. The performance optimization is very promising. For an optimized language such as Java the increase in speed is marginal. Some performance increase can be found in the stream functionality. However for a non optimized language, such as Ruby, the gain in speed can be substantial. In a following blog post we’ll take a deeper look at what Graal is and how it works.
SubstrateVM is probably one of the most discussed and talked about components of the GraalVM. In short “Substrate VM is a framework that allows ahead-of-time (AOT) compilation of Java applications under closed-world assumption into executable images or shared objects”. This means that you can create native executable code that runs without the VM. When starting the code it runs directly on your machine without any interpretation of a VM. So fast startup and processing time is one of the biggest promises. Imagine a very small docker container with your Java code compiled ahead of time, or serverless computing with a native Java image. In the following post we’ll explain the possibilities and (current) limitations of Substrate VM.
GraalVM looks like a very promising new technology that offers a lot of features and which can have a large impact in the world of IT. New and Old languages can benefit from this project. Although it still has an RC status, it already looks very promising. Out of the box you already have a lot of language interpreters, and because of the popularity of GraalVM, we expect that this number will only increase. The Graal compiler and its features also look promising.
Although you can read a lot about what Substrate VM cannot do at the moment, it already contains a lot of functionality that allows you to create a native executable with a high level language such as java.
In short we are looking forward to the first official release of GraalVM and we are expecting a lot of new features in the future.