GraalVM background

The rise and rise of old and new programming languages shows that there must be demand for things like the Internet for JavaScript, artificial intelligence for Python, microservices for Golang, and so on. We all know that it’s unlikely that any language will prevail in every field, and Java is the closest thing we have to that goal. But if you want to go one step further, you might as well forget about the Java language and go one step further.

  • Further improving the performance of programs running on the JVM
  • Compile Java programs into native executables by ahead-of-time
  • Multiple programming languages in one program (Polyglot)
  • Like LLVM, GraalVM also provides a convenient mechanism for developing new programming languages

The current pain points

In the cloud native era, Java programs are at a major disadvantage. Why? The average Java application has tens of megabytes of memory and is not fast to start.

The most popular SpringBoot/SpringCloud microservices framework, for example, requires at least 3-4 seconds to start an application that has been optimized with many beans requiring lazy load, hundreds of megabytes of memory, and slightly more complex business logic. Is it difficult to meet business needs without more than 1 GB of memory?

So in the era of cloud native, a JVM full of dark technology has been introduced that can help us start Up Java programs 100 times faster, with a fifth of the memory, or less.

The introduction of Graalvm

  • GraalVM is the next generation JVM implementation developed by Oracle in 2018. Officially called “Universal VM” and “Polyglot VM”, GraalVM is a cross-language full-stack VIRTUAL machine enhanced on top of the HotSpot VIRTUAL machine. Can be used as a platform for “any language”.
  • “Any language” includes Java, Scala, Groovy, Kotlin, and llVM-based languages such as C, C++, and Rust. It also supports other languages such as JavaScript, Ruby, Python, and R.

GraalVM can mix and match these programming languages without additional overhead, supporting the mixing of interfaces and objects from different languages, and supporting the use of native library files already written for these languages.

Its slogan, “Run Programs Faster Anywhere”, has a tinge of ambition

Comparison of Graalvm performance

GraalVM’s performance is really good. Take JDK 8 as an example

  • OpenJDK
  • Oracle JDK

OpenJDK is open source through the “GPL V2 with CE” protocol and can be commercially available for free.

Oracle JDK is generally 30% faster than OpenJDK for a query with a small amount of data.

  • GraalVM is divided into community edition and commercial edition. GraalVM community edition is also open source using the same “GPL V2 with CE” protocol as OpenJDK.
  • The Community edition of GraalVM is also surprisingly 10% faster than the Oracle JDK.
  • The commercial version of GraalVM has not been tried, and it is officially reported that the commercial version has more performance improvements than the community version

Main features of Graalvm

  • High-performance modern Java
  • Occupies less resources and starts quickly
  • Mixed programming with JavaScript,Java, Ruby, and R
  • Running native languages on the JVM
  • Cross-language tools
  • JVM Application Extensions
  • Native App expansion
  • Local Java library
  • The database supports multiple languages
  • Create your own language

How Graalvm works

GraalVM basically works by taking the source code of these languages (for example, JavaScript) or the compiled intermediate format of the source code (for example, LLVM bytecode, Class bytecode) is converted by the interpreter into Intermediate Representation (IR) that can be accepted by GraalVM. For example, an interpreter is designed to convert the bytecode output by LLVM to support C and C++ languages. This process is called Specialized (also known as Partial Evaluation).

GraalVM provides the Truffle toolset to quickly build an interpreter for a new language, and uses it to build a high-performance LLVM bytecode interpreter called Sulong.

From one perspective, GraalVM is a true high-level language virtual machine equivalent to a physical computer because, like the instruction set of physical hardware, GraalVM is related only to machine features and not to a high-level language feature.

Graalvm’s advanced optimization capabilities

Thomas Wuerthinger, director of research at Oracle Labs, said in an interview: “With the release of GraalVM1.0, it has been proven that it is possible to have high-performance multilingual virtual machines, and that the best way to achieve this goal is not through bytecode with language features like the Java virtual machine and the Microsoft CLR.”

Since GraalVM automatically optimizes the intermediate representation of input and optimizes on-the-fly compilation at runtime, GraalVM implementations often achieve better performance than native compilers. For example, graal. js is better than Node.js, Graal.Python is better than CPtyhon, TruffleRuby is better than Ruby MRI, FastR is better than R, and so on.

Graalvm vs. Hotspot

GraalVM was born out of HotSpot and is designed to be used as a complete set of Java SE8 compliant Virtual machines.

The main difference between it and standard HotSpot is the just-in-time compiler, and its execution efficiency and compilation quality are currently at par with standard HotSpot.

All of the latest just-in-time compilation research done by Oracle Labs and research institutes in American universities has been migrated to GraalVM based, and the potential for growth is very exciting.

GraalVM is now the most promising candidate if the Java language or HotSpot VIRTUAL machine will ever be replaced. The revolution is likely to creep in without Java users noticing it, and the entire software ecosystem in the Java world will remain unchanged. But the number one position has quietly changed.

Graalvm instant compiler

Since JDK 10 HotSpot has added a new just-in-time compiler: the Graal compiler, whose name suggests it comes from the Graal VM.

C1/C2 just-in-time compiler

In applications that require a long run, where hot code is captured by HotSpot’s detection mechanism and compiled into machine code that can be executed directly by the physical hardware, Java’s efficiency depends largely on the quality of the code output from the just-in-time compiler.

The HotSpot VIRTUAL machine includes two just-in-time compilers:

  • Client-side compiler with short compile times but less optimized output code (abbreviated C1)
  • A server-side compiler that takes longer to compile but optimizes output code with higher quality (ABBREVIATED C2)

Usually they work with the interpreter under a hierarchical compilation mechanism to form the HotSpot VIRTUAL machine’s execution subsystem.

C2 instant compiler

The Graal compiler was introduced as a replacement for the C2 compiler. C2 has a long history, dating back to the doctoral work of Cliff Click, a compiler written in C++ that, while still working well, has become so complex that even Cliff Click himself is reluctant to maintain it.

Graal compiler

The Graal compiler itself is written in Java and is deliberately implemented in the same “sea-of-Nodes” High IR form as C2, making it easier to leverage the benefits of C2.

The Graal compiler came out twenty years later than the C2 compiler and has the advantage of being a late mover. While maintaining the compiled code output of similar quality, the development efficiency and scalability of Graal compiler are significantly better than C2 compiler. This means that the best code optimizations in the C2 compiler can be easily ported to the Graal compiler, whereas the best optimizations in the Graal compiler are much harder to implement in the C2 compiler.

In this case, Graal’s compilation performance quickly caught up with C2’s in just a few years, and even began to surpass C2’s in some tests.

Graal can do more complex optimizations than C2:

  • Partial Escape Analysis
  • It is easier to use “Aggressive Predictive Optimization” strategies than C2
  • Support for custom predictive assumptions
It should be a future

The Graal compiler is still young and has not been tested enough, so it still carries the “experimental status” tag and needs to be activated with a switch parameter. This reminds me of the scene in JDK 1.3 when HotSpot VIRTUAL machine was first released and also needed to be activated with a switch. It also has a history as a replacement for the Classic VIRTUAL machine.

The future of the Graal compiler is promising. As the latest engine for executing Java VIRTUAL machine code, its continuous improvement will inject faster and stronger driving force into both HotSpot and Graal VM.

Compile to native executor

There are certain assumptions for compiling native programs, such as:

  • Make as few JNI calls as possible
  • Use reflection as little as possible
  • Minimize class loader isolation, etc

When these complex features are not available, it is easy to compile jars into executable programs using the Native image provided by GraalVM.

Of course, even when the application uses JNI, reflection, it doesn’t matter, we can use some configuration files to tell GraalVM to process this information separately, such as:

  • JNI is told to configure the JSON file with the -h :JNIConfigurationFiles parameter
  • Through the parameter – H: ReflectionConfigurationFiles tell reflection JSON related configuration file

It’s a little more complicated, but with enough patience, it’s theoretically possible to compile!

However, we can use some frameworks that support GraalVM Native image, such as Quarkus.

GraalVM’s native compilation is ideal for microservices and Serverless

When it became possible to compile Java programs as native executables (currently GraalVM already supports compiling native programs for Windows, MacOS, and Linux), the two major changes were:

  • The startup time is shorter. It used to take more than 2 seconds to start a Java program with dependency injection. If Java programs are intended to run for a long time, a slightly slower startup time is fine, but for Serverless applications, it becomes a cold start, which can be a big impact.
  • The memory requirement for the program to run is smaller. A Java program that used to have good heap control (the heap setting is small) needs more than 100M memory, but when compiled as a native program, it needs only 4M memory. The same machine can then start a very large number of processes, suitable for simple microservices.

If you are interested in the Java Virtual Machine, you can click here to watch it