1. Introduction
In this last part of the tutorial we are going to speculate about the future of GraalVM, both from the short-term and long-term perspective. I think there are three main themes which GraalVM is going to evolve:
- Improving native image technology
- Improving and optimizing GraalVM JIT compiler
- Improving Truffle and including more Truffle languages
Let us briefly talk about some ongoing and already completed work in these directions.
Table Of Contents
2. Closing the gap
Along the previous parts of the tutorial we mentioned a number of the limitations associated with building native image on GraalVM, however the situation has changed since then.
Just recently the serialization support was added to native image, managed through the new property -H:SerializationConfigurationResources. The tracing Java agent is now capable to capture the serialization activities and output them into serialization-config.json file.
Also, the recent 21.0.x release brings a full support of the method handles. Methods accessed through method handles will have to be registered in the same configuration file as the reflection methods, and this configuration could be automatically generated through the tracing Java agent. Please notice that the VarHandles that are not stored in static fields are still not supported.
And even that is not all. A new web-based GraalVM Dashboard tool has been announced recently (in beta). It is a dashboard for visualizing arbitrary aspects of dynamic and static compilations in GraalVM and native image. The tool has been designed to display the information on methods compilation, reachability, class usability, profiling data, and even information about dynamic compilation pressure, compiled code lifetime, compilation count, deoptimization etc. Currently it is available as a hosted option and it supports only Native Image Dump Format which could be produced by passing command line options:
-H:DashboardDump=<path>to define the path for the dump file-H:+DashboardAllto dump all available data
So what else is cooking for native image?
- Module support for native-image building: https://github.com/oracle/graal/issues/1962
- Improve support for resource bundles and locales: https://github.com/oracle/graal/issues/2982
- Support dynamic class loading: https://github.com/oracle/graal/pull/2442
- Add JDK Flight Recorder support for Java native images: https://github.com/oracle/graal/pull/3070, https://github.com/oracle/graal/pull/3155
- Native Image GC Improvements: https://github.com/oracle/graal/issues/2386
- Support for ZGC: https://github.com/oracle/graal/issues/2149
- Implement Shenandoah barriers : https://github.com/oracle/graal/pull/2426
As you may conclude from the above, supporting different GCs is the most demanded feature. Besides that, there are a few notable Truffle developments going on:
- GraalVM Thermometer tool: https://github.com/oracle/graal/pull/3198
- Support for Inspecting Available Stack Memory: https://github.com/oracle/graal/issues/3154
- A numerous requests for more language implementations (https://github.com/oracle/graal/issues/361, https://github.com/oracle/graal/issues/499, https://github.com/oracle/graal/issues/437, https://github.com/oracle/graal/issues/381, https://github.com/oracle/graal/issues/349, …)
On a slightly different note, a kindly prepared GraalVM Quick Reference summarizes all key GraalVM options and commands to illustrate its capabilities.
3. Ecosystem Maturity
Undoubtedly, the ecosystem around GraalVM is maturing very fast. The new versions of the Micronaut, Helidon and Quarkus are dropped regularly, adding stability and supporting more libraries and integrations. The Spring Native has been graduated to beta, an important milestone in the multiyear journey towards production readiness.
4. Alternative Distributions
Another trend we are seeing is an appearance of the alternative distributions based on GraalVM community edition. The first one is Mandrel, a community distribution of GraalVM for the Red Hat build of Quarkus.
Mandrel is a downstream distribution of the GraalVM community edition. Mandrel‘s main goal is to provide a
native-imagerelease specifically to support Quarkus. The aim is to align thenative-imagecapabilities from GraalVM with OpenJDK and Red Hat Enterprise Linux libraries to improve maintainability for native Quarkus applications.
The other one is Liberica Native Image Kit (or shortly, Liberica NIK) by BellSoft, a well-known vendor of the similarly named Liberica JDK distribution.
Liberica Native Image Kit (Liberica NIK) is a utility that converts your JVM-based application into a fully AOT compiled native executable under the closed-world assumption with an almost instant startup time. It is based on the open source GraalVM Community Edition. Being compatible with various platforms, including lightweight musl-based Alpine Linux, this technology optimizes resource consumption and minimizes the static footprint.
https://bell-sw.com/announcements/2021/02/19/BellSoft-releases-Liberica-Native-Image-Kit/
It is very likely that we should anticipate more vendors jumping in and providing own tailored GraalVM distributions, augmented with additional features, tooling and support.
5. Project Leyden
At some point it became clear that the scope of native image (and in general, AOT compilation on JVM) goes way beyond just GraalVM. Exactly a year ago, the new Project Leyden has been announced with the ambitious goals to standardize native static images at JVM platform level.
Unfortunately, there are not many details available on the Project Leyden today and it seems like its establishment is still ongoing. Meantime, the experimental jaotc command line tool has been removed from OpenJDK distributions starting from JDK 16. What is next is unclear, hopefully more details on the Project Leyden are going to emerge soon.
6. Conclusions
Here comes to the end the introductory tutorial into GraalVM community edition. Hopefully this technology had caught your attention and is going to find its way into your projects or / and organizations. It is hard to predict the future being an insider, even harder being an outsider, but every pointer hints that GraalVM is here to stay. It is unclear how the relationship between GraalVM and OpenJDK are going to evolve, however it is heartbreaking to see the inspiring projects coming out of this partnership.
