GraalVM is the next generation of Java virtual machine released by Oracle. The first release was released in 2019.05, with community and enterprise versions respectively

GraalVM has three major features

1. Run Java efficiently

Java programs can be executed faster using GraalVM. GraalVM is able to run Java applications more efficiently because it uses Graal compiler technology, which is a JIT compiler, but what is a JIT compiler?

In practice, compilers in Java can be divided into the front-end compiler, which is the process of compiling.java into.class, and the runtime compiler, which is the process of converting.class bytecode into machine code. The run-time Compiler is called Just In Time Compiler, so it can be shortened to JIT Compiler

The JVM development team originally put most of the code optimization in the runtime compiler JIT, while the front-end compiler Javac had little code optimization because it allowed.class files that were not generated by javAC to take advantage of compiler optimization. The front-end compiler Javac is specifically responsible for dealing with Java’s syntactic sugar and converting it into normal bytecode, so it can be said that the front-end compiler JavAC is responsible for improving programmer development efficiency, while running its compiler JIT is responsible for increasing code speed

  • The front-end compiler Javac is responsible for converting the syntactic sugar in Java into normal bytecode
  • [Runtime compiler] JIT: Responsible for code optimization

Now that we know about the JIT compiler, let’s go back to the Graal compiler

The Graal compiler is a JIT compiler written in Java, although it might be tempting to think that the performance of the C2 compiler written in C++ is inferior to that of HotSpot. However, after various experiments, the data showed that for Java applications, Graal compilers are almost as capable as C2 compilers (once warmed up)

For Scala applications, the Graal compiler is more than 10% optimized, which is why Twitter is replacing HotspotVM with GraalVM on a large scale

2. Multilingual parallelism

You can use multiple languages simultaneously in Java, such as JavaScript, R… (including languages running on JVM and not JVM.) Personally, I feel that there are not so many scenarios for this function in most Chinese enterprises, most of which are relatively single language use is enough, for me, this function is relatively weak.

3. Quick start

GraalVM has one last feature, Native Image Quick launch, which compiles Java applications directly to machine code at compile time, allowing the program to run as a normal binary file

The advantage brought by [Native Image] is that it can start a Java application more quickly. In the past, if you want to start a Java program, you need to start the JVM first and then load the Java code, and then immediately compile the.class bytecode into machine code and hand it to the machine for execution, which is very time-consuming and memory consuming. If native image is used, a smaller and faster image can be obtained, which is suitable for cloud deployment

The reason why Native image can be started quickly is that it uses ahead-of-time compile at the bottom. That is to say, it compiles all relevant things, including a base VM, into machine code during compilation. This base VM is internal to GraalVM and contains only the most basic thread alignment mechanism, garbage collection, and the necessary JVM size as small as possible

Although Native Image sounds impressive, it also has an ineffable disadvantage, that is, the throughput of programs using Native Image will decrease, because a large part of the optimization of Java programs is in the JIT compiler. However, Native image does not use any benefits provided by JIT. Another disadvantage is that There is no way for Native image to load classes dynamically (because everything has to be decided at compile time), so there is no way to use reflection and other related mechanisms

However, GraalVM also proposes a corresponding solution to this problem, which is to compile all possible classes in the compilation, so the reflection mechanism is still supported, otherwise, the whole Spring Framework will not be able to use native image. Currently, Spring 5 is also planning to support GraalVM Native Image Settings out of the box. We can imagine that serverless computing may be the future trend of Java applications. After all, the original intention of serverless computing can be achieved only with the fast startup feature of Native Image