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
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
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, …)
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.
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 ahttps://github.com/graalvm/mandrel
native-imagerelease specifically to support Quarkus. The aim is to align the
native-imagecapabilities from GraalVM with OpenJDK and Red Hat Enterprise Linux libraries to improve maintainability for native Quarkus applications.
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.
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.
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.