- Why GraalVM?
- Getting Started
- Container Images
- Reference Manuals
- Debugging and Monitoring Tools
- GraalVM as a Platform
- Security Guide
- Release Notes
- Version Roadmap
- GraalVM 21.3.x
- GraalVM 21.2.x
- GraalVM 21.1.x
- GraalVM 21.0.x
- GraalVM 20.3.x
- GraalVM 20.2.x
- GraalVM 20.1.x
- GraalVM 20.0.x
- GraalVM 19.3.x
- GraalVM 19.2.x
- GraalVM 19.1.x
- GraalVM 19.0.x
- Release Candidates
- Known Issues
This is a hotfix release for the GraalVM 21.2.x branch. It contains some operational fixes as:
- [GraalVM Enterprise] Fixed a
StringBuilderoptimization issue in Java 11 based GraalVM to improve special characters parsing (see #3627).
- Fixed issue with
strspnused in the
dateC extension compiled as a macro on older
glibcand then missing the
__strspn_c1symbol on newer
- Java and Compiler Updates
- Platform Updates
- Native Image
- Polyglot Runtime
- Java on Truffle
- LLVM Runtime
- Polyglot Embedding
- Truffle Language and Tool Implementations
Java and Compiler Updates #
- The OpenJDK release that GraalVM Community Edition is built on was updated to:
- The Oracle JDK release that GraalVM Enterprise Edition is built on was updated to:
- [GraalVM Enterprise] Improved loop limit analysis for counted loops. The compiler will now detect and refine the range of an induction variable by taking the preceding conditions into account. When the loop is counted, it becomes amendable for advanced optimizations like partial unrolling, inversion, and vectorization. Read more here.
- [GraalVM Enterprise] Added a novel SIMD (Single Instruction Multiple Data) vectorization optimization for sequential code. This optimization is disabled by default until the 21.3 release. Enable it with
- [GraalVM Enterprise] Added a novel Strip Mining optimization for non-counted loops. Strip mining is disabled per default. Enable it with the
- [GraalVM Enterprise] The existing
StringBuilderOptimizationPhaseperforms high level transformations on
StringBuilderpatterns to directly construct the final
Stringand eliminate unnecessary intermediate
StringBuilders. This release adds support for this optimization in JDK11 by adding support for the compact
Stringrepresentation used in the JDK. The core optimizations were improved to handle more code shapes and to constant fold more operations.
- [GraalVM Enterprise] Improved safepoint elimination in long counted loops. The compiler can now eliminate safepoints in loops that have a
longinduction variable (as opposed to an
int) where it can statically prove that the range of the induction variable (i.e., the maximum number of iterations) is
Integer.MAX_VALUE - Integer.MIN_VALUEwhile previously it would only consider
int-typed induction variables. Read more here.
- [GraalVM Enterprise] Added an optimization that tries to move writes out of loops, called “Write Sinking.” Write Sinking is an experimental feature disabled by default. Enable it with
- Implemented a Speculative Guard Movement optimization that tries to move a loop invariant guard (e.g., an array bounds check) inside a loop to outside the loop. This change improves the geomean throughput score of GraalVM Community on SpecJVM2008 by 4.2%. The scores on the Renaissance, DaCapo, and ScalaDacapo benchmarks also increased by about 0.5%. Disable it with
- Added intrinsic for
PhantomReference.refersTojust like it was done for C2.
- Added support for applying counted loop optimizations to
whileloops whose first iteration is not guarded by the loop condition.
- Added guard hoisting loop duplication phase which should contribute to ahead-of-time compilation flow (GraalVM Native Image). It splits certain loops into “fast” and “slow” versions. The fast loop is chosen if we know at run time that no exceptions can happen. The fast loop allows more loop optimizations and loop vectorization. Loop duplication needs the profile-guided optimizations data. Disable it with
- Improved the Graal compiler to allow compiling ahead-of-time methods with more than 64 loops. This resolves a problem that was preventing Native Image from compiling programs with more than 64 loops in a method body. This is a pattern often seen in generated Java code, such as that output by tools such as ANTLR.
Platform Updates #
- Linux AArch64: GraalVM distributions for AArch64 CPU architecture are released as supported in 21.2 with more features enabled, like Ruby runtime, and Java on Truffle (Espresso).
- Java 16 support: GraalVM builds based on Oracle JDK 16 or OpenJDK 16 remain experimental in this release, but have become more “mature” by overcoming some known limitations and adding support for Ruby, Python, and WebAssembly runtimes.
Native Image #
- Released new official Gradle and Maven plugins for Native Image with initial JUnit 5 testing support. These plugins will make building, testing, and running Java applications as native executables much easier, and the native JUnit support allows JVM libraries to run their test suites via GraalVM Native Image. For more details, read the announcement blog post.
- Added basic Java Flight Recorder (JFR) support on JDK 11. This feature was developed in a cooperation between Oracle and RedHat. Native images that are built with
-H:+AllowVMInspectionsupport JFR events that are written in Java (see
jdk.jfr.Event). To record JFR events at run time, JFR support and JFR recording must be enabled. Check the documentation or see the help message for
-XX:StartFlightRecordingoptions. At the moment, JFR support is still significantly limited, i.e., most VM-internal events and also most advanced features such as stack traces or memory leak detection are still missing.
- Improved resource handling: resources stored in the image can be accessed through a virtual file system.
- Implemented the class pre-definition: to support
ClassLoader.loadClassat run time, classes that need to be loaded at run time can be made available to the static analysis so that they are included in the closed-world analysis. This improves compatibility with libraries that rely on dynamic class loading, as long as the classes loaded or generated at run time are stable. This feature was developed in cooperation with Oracle and Alibaba.
- Removed unnecessary security providers from the image: the reachable security providers are automatically detected by the static analysis. We fixed some bugs that made too many providers reachable in some cases, leading to large and non-deterministic image sizes. It is now also possible to disable the automatic detection completely using
- Added an “epsilon” GC to build an image without any garbage collector, which is applicable for very short running applications that only allocate a small amount of memory. The application fails when more than the maximum heap size is allocated. Enable it at image build time with
- Changed the
--initialize-at-build-timeoption behaviour to be used only with arguments. This prevents users to write non-composable code and to avoid accidental semantic errors.
Polyglot Runtime #
- Added a new compilation queuing heuristic enabled by default. The new heuristic improves the warmup time of the polyglot runtime on many workloads. It detects code being currently executed and prioritizes the compilation of such code. The new queue implementation also uses dynamic compilation thresholds that increase and decrease compilation thresholds depending on the load of the compilation queue. The new heuristic can be enabled or disabled using
--engine.TraversingCompilationQueue=true|false. A more detailed description of the new heuristic can be found here.
- VM inspection is now enabled in all launchers by default. It is no longer necessary to rebuild the language launcher image to enable inspection. The
SIGQUITsignal can now be used to print thread dumps at any point during their execution. By additionally enabling the performance counters with the
--vm.XX:+UsePerfDataoption in GraalVM Enterprise, VisualVM is able to attach and monitor language launchers that run with
Java on Truffle #
- Introduced Truffle on Java HotSwap Plugin API which allows to reload the code without the need for restarting a running application. It is meant for framework developers to reflect changes to, e.g., annotations, framework-specific updates such as implemented services or beans. For more details, check the documentation.
- Improved bytecode dispatch, yielding a 15-30% interpreter speed-up.
- Added a new static object model implementation that dynamically generates host classes at run time. It is experimental at the moment.
- Added fixes to prevent crashes when external threads enter Espresso and call native code.
- Fixed crashes when running with older versions of GNU libc (<= 2.17).
- Added support for additional interoperability messages for guest objects implementing
-engine.WarnInterpreterOnly=falseoption or the
- Added the
js.unhandled-rejectionsoption to track unhandled promise rejections in a polyglot
Context. By default, the option is set to
none, and unhandled promise rejections are not tracked.
- Implemented the New Set Methods proposal. It is available behind an experimental flag (
- Implemented experimental operator overloading support. Use the experimental option
--js.operator-overloadingto enable it and consult the documentation.
- Updated the RegExp Match Indices proposal with opt-in using the
dflag. Available in ECMAScript 2022 (
-js.ecmascript-version=2022). Deprecated the
The changelog is available in the project repository.
- GraalVM’s WebAssembly now correctly detects memory-allocation failures, and throws WebAssembly errors as per specification (
RangeErrorexception), instead of returning internal engine errors.
- Fixed edge-cases in calls to functions from imported tables. In indirect calls (
call_indirectinstruction) GraalWasm will now correctly type-check the function type when the function is exported from a different module and set as an entry in an imported table.
- Improved detection of some arithmetic errors, printing out a more specific type of the arithmetic exception. In the earlier version, handling of certain arithmetic errors caused a
- Performed general maintenance work and fixed bugs to pass tests for as many NPM modules that use WebAssembly as possible.
LLVM Runtime #
- [GraalVM Enterprise] Added support for
pthreadsynchronization primitives in managed mode such as
pthread_cond, and more. This enables a user to run multi-threaded programs. Previously, it would just fail when a user tried to run a multi-threaded software.
- [GraalVM Enterprise] Updated
musl libcto version 1.2.2.
- Added support for C++ virtual calls via cross-language interoperability.
- Added support for atomic versions of already existing assembly instructions. This means that the LLVM runtime now has wider support for inline assembly, especially for multi-threaded software.
- Fixed GraalVM’s LLVM toolchain not working correctly for C++ on MacOS 11.3 (see #3383.
The project changelog is available on GitHub.
Ruby (TruffleRuby) #
- Implemented the precise invalidation for Ruby methods and constants, by using per-name and per-class assumptions.
- Updated to Ruby 2.7.3 (fixes CVE-2021-28965 and CVE-2021-28966). The
resolvstdlib was not updated (
resolvin 2.7.3 has bugs).
- Fixed the LLVM toolchain issue on macOS 10.13 (see #3383).
- Improved the
#digmethod to make iteration through arrays and hashes faster and compile better for calls with 3+ arguments (see #2301).
- Improved fiber-local variables by using less synchronization which made them faster.
TruffleSafepointis now used instead of custom logic, which no longer invalidates JIT-ed code for guest safepoints (e.g.,
A full list of changes is available in the changelog.
- [GraalVM Enterprise] Implemented
_pickleas a faster version than the pure Python version. GraalVM Enterprise users will see better performance when serializing objects across the network.
- Improved Python performance especially during warmup and in shared engine configurations by adding fast paths, intrinsifying functions, and adding optimized representations for common data structures.
- Applied the new Truffle safepoint mechanism for more efficient GIL releases, signal handlers, and weak reference callbacks.
- Updated the supported HPy version to 0.0.2.
- Added support for the
dicttype properly using the new hash interoperability messages. Now Python dictionaries can be cast to
java.util.Mapand behave as expected when using Python from Java.
- GraalVM Python runtime now passes more compatibility tests for
crypt, and more functions in
time. The code written for Python 3.8 that uses these can be expected to work better now.
- Added initial support for the
psutilpackage which enables system access and processes monitoring, and for the
PyGamemodules designed for writing video games.
- GraalVM’s Python no longer unconditionally creates
_pycache_if the file name “sitecustomize.py” exists in the current working directory.
More details can be found in the changelog.
- Continued improving the compatibility with R 4.0.3. For example, the support for
testthat3.0.1 packages was significantly improved.
- Packages with known issues,
knitr1.31, still remain.
More details are available in the project changelog.
Visual Studio Code
- Renamed extensions for VS Code as following:
- GraalVM Tools for Java
- GraalVM Extension Pack for Java
- GraalVM Tools for Micronaut
GraalVM Tools for Java Extension
- Implemented full support of JDK16 and its language features.
- Added support for developing, running, and debugging single Java class, supported from JDK8 and beyond.
Introduced a wizard to easily create a new Java project:
Introduced a new class wizard “Java: New From Template” that allows to add various Java and related files to a project:
Implemented the possibility to attach a debugger to a running process. Available via Run and Debug “Java 8+…” configuration.
- Improved Java code navigation with “GoTo Type”, “Find Usages” options.
- Enabled the Native Image agent to gather the configuration data in the “Run without Debugger” mode. This makes it easier to build native images from VS Code. Use a special launch configuration Launch Java 8+ Application With Native Image Agent. Check this feature documentation for more details.
GraalVM Tools for Micronaut Extension
- Added “Launch Java: Continuous Mode” launch configuration also known as “Run Dev Mode” for Gradle and Maven projects:
- Developed and ran Spock tests in the Groovy language. Included code completion and other editing support for Groovy.
VisualVM and VS Code Integration
- Added a special section to the VS Code Gr activity to control the VisualVM tool included in the active GraalVM installation. Find more information in this feature documentation, but the major updates are:
- Enabled to start VisualVM along with the VS Code project
- Provided actions to take a thread or heap dump, and to configure and control CPU/Memory sampling and JFR recording
- Enabled the Go to Source action in VisualVM views which opens the sources back in VS Code
- Added a feature that allows to save JFR recording from live process (see #297).
- Implemented a lock contentions profiling feature, by adding a Lock Contention view in the Profiler tab (see #298).
- Added support for JDK 17.
- Enabled controlling VisualVM instance from the command line or an external tool: start sampling (#321), control flight recording (#322), taking a thread (#319) or a heap dump (#320) of a Java process from the terminal.
- Published Maven artifacts for VisualVM.
Polyglot Embedding #
As announced in the 21.1 release notes, we have updated the required JVMCI version for Polyglot Embeddings in this release. All GraalVM JDK versions (8, 11, 16) already contain the updated JVMCI version and there is no further action required. If you are using a different JDK than GraalVM and you have configured the Graal compiler on the upgrade module path you will need one of the following JDK versions that includes JDK-8264016 for full compatibility:
- Other JDK 11: Oracle JDK 11.0.13 (2021-10-19), OpenJDK is still to be determined.
- Other JDK 16: No current plans to update JVMCI.
- Other JDK 17: The new JVMCI version is already integrated into early access builds.
If your JVMCI version is outdated, you will be able to use GraalVM embeddings, but forced context cancellation (
Context.close(true)) and interrupt (
Context.interrupt(Duration)) will throw an error. We recommend the following workarounds:
- Do not use forced context cancellation or interrupt. All other features are still supported.
- Switch to the fallback runtime by removing graal.jar from the upgrade-module-path. Note that this will significantly worsen performance and should only be a last resort.
- Wait with upgrading to 21.2 until the JDK version has support for the new JVMCI version.
- Changed the behaviour of
Value.as(TypeLiteral<Function<Object, Object>>).apply(): when the function is called with an
Objectargument, it is passed through as a single argument rather than an array of arguments (see #456).
A full list of changes can be found here.
Truffle Language and Tool Implementations #
- Added support for Truffle libraries to be prepared for ahead-of-time compilation without prior execution. See ExportLibrary.useForAOT or the AOT Tutorial for more details.
equals()to provide results of the interoperability
identityHashCodeand isIdentical calls on the corresponding guest objects, respectively.
- Added support for iterators and hash maps to
DebugValue. The added methods delegate to the respective methods of
- Methods annotated with
@Fallbackof the Truffle specialization DSL now support
TruffleContext.resume(Future<Void>)to pause and resume execution for a Truffle context, respectively.
CompilerDirectives.blackhole(value)which can be helpful for benchmarking.
Closeablefor automatic close on context dispose.
RootNode#isInternal()as the criterion that determines whether a frame with the given root node counts towards the stack trace limit.
MemoryFencewhich provides methods for fine-grained control of memory ordering (see #2031).
Object.equals(Object)cannot safely be used on compiled code paths. Use the Truffle Specialization DSL instead to implement caches with equality semantics. Making
Object.equals(Object)reachable as runtime compiled method will mark too many equals implementations reachable for runtime compilation in a native image.
- Deprecated and added methods to support expected arity ranges in
ArityExceptioninstances. Note that the replacement methods now include more strict validations.
- The Specialization DSL now generates code to throw an
@Cachedparameter returns a non-null value and is used in a guard. The null state is reserved for the uninitialized state.
LoopConditionProfile#create()as an alias of
createCountingProfile()so it can be used like
@Cached LoopConditionProfile loopProfile.
A full list of changes can be found here.