What Is GraalVM and Why Is It Useful

At Swan Software Solutions, our team has a variety of skills that allow them to exceed client expectations. Eugene works as a Full-Stack Developer. His hobbies include spending time with friends, exploring nature, playing guitar, and coding. He hopes to continue to improve his knowledge and skills with the goal of mentoring a team in the future.

Eugene states, “I think the most important trait of a good developer is to be ready to learn the new technologies of his stack, so he can apply his actual knowledge in projects.” In this blog, Eugene shares about GraalVM.

The GraalVM project was started in 2012 by Thomas Würtinger at the Swiss branch of Oracle Labs. Oracle is the owner and developer of this project called – “Maxine Virtual Machine”. Würtinger has reduced his activity on the project, and now the main work is done by Douglas Simon, Christian Hamer, and Josef Aisley.

What is the internal structure of GraalVM?

GraalVM includes standard HotSpot JDK (with support for compiling Java applications). GraalVM Community Edition uses OpenJDK and Enterprise Edition – Oracle JDK. The next component is the compiler, which is called Graal. The Graal compiler supports already known JIT compilation (converting bytecode into machine code).

Why do we need another JIT compiler?

The main difference – GraalVM is written in Java (not C⁺⁺) which is more productive. Moreover, it was developed for high-load applications. One disadvantage is that since Graal is written in Java, it is necessary to include HotSpot JDK in GraalVM for its performance. But there will be an even stronger increase in application performance when compiling in AOT mode. This mode has been known by developers of front-end applications. Therefore, the maximum gain in performance/memory consumption you will get when using AOT mode. This will help solve one of the biggest problems of JVM applications – low performance and higher memory consumption compared with the same C⁺⁺ applications. If your application does not support it, works with errors, then the only option – GraalVM and JIT-compiler.

GraalVM has violated one of the inviolable tenets of Java development – “Write Once, Run Anywhere.” But everything has changed with the advent of virtualization and Docker containers. If we pack the application in the Docker image, then we do not need an intermediate stage in the form of obtaining bytecode. We do not need the JDK/JRE in the Docker image, and the image size will be reduced several times. The main thing is that the compilation of Native Image Builder took a reasonable time.

What about debugging?

The Native Image utility supports special arguments for generating debug information in GDB-compliant format. Unfortunately, debugging of Java applications is not supported, which, in principle, is very rarely required for production.

So, GraalVM is a set of components – JIT-compiler; API for implementing language parsers (Truffle); and Abstract Virtual Machine (GraalVM Runtime), whose main goal is to make the development of new languages ​​cheap and easy, as well as speed up modern programming languages ​​by using existing ones’ optimizations in Hotspot.

As you can see, GraalVM has its advantages and limitations, but overall, it’s a new and exciting stage of application development.

Swan appreciates our team member Eugene taking the time to share about GraalVM. To find out more about how Swan could help your company meet its technology needs, contact us.

Swan Software Solutions is an international company, and many of our team members–including Eugene–are Ukrainian. We are doing everything we can to support our team throughout this war. If you would like to help, here is an easy way to do so. Indiana Supports Ukraine