- GraalVM JDK 11 Based Builds
- GraalVM JDK 11 on ARM64
- Native Image
- Native Image Maven Plugin
- GraalVM Compiler
- LLVM Interpreter
- Visual Studio Code Extensions
- Changes for GraalVM Embedders (SDK)
- Changes for GraalVM Language or Tool Implementers (Truffle)
This is a bugfix update including fixes to the JVM Compiler Interface (JVMCI) and necessary updates to the JDK 11 support.The following issues were addressed:
- Approached the issue of
DynamicProxySupportbeing not thread safe when
DynamicProxySupport.addProxyClassis called from multiple threads (see #1927).
- Resolved a problem leading to a wrong execution of the code produced with the GraalVM
native-imagebuilder at optimization level 2
- Fixed a problem when JavaFX applications misbehave with
- Resolved an issue of VM crashing when run with Serial GC (see #1892).
ReduceInitialCardMarksis unsafe with
OptBulkAllocationin JDK 11 (see #1915).
- Fixed a transient crash while building native images with GraalVM based on JDK11 (see #1906).
GraalVM 19.3 is the first planned long-term support (LTS) release built from themain line of the project. This is also a major feature release and it is arecommended upgrade. The LTS status assures that stability, security, andperformance fixes will be backported from the current branch until the next LTSrelease that should occur as the last major release of 2020. The LTS designationshould provide a level of stability for developers to work with.
With the major update to the 19.3 version, we announce the first release ofGraalVM based on JDK 11! This represents a substantial milestone given thedifferences between JDK 8 and JDK 11. In particular, the Java Platform ModuleSystem (JPMS) introduced in JDK 9 means GraalVM now uses module encapsulation to isolate code such as JVMCI, the GraalVM compiler and the Truffle API from application code. In addition, it means GraalVM on JDK 11 includes all theJDK changes since JDK 8. These are detailed in the release notes for JDK 9,JDK 10and JDK 11.
In terms of languages, GraalVM on JDK11 supports all JVM languages (Java, Scala etc.) aswell as all guest languages currently supported in GraalVM on JDK8.Due to the modular structure of the base JDK, there is no more $GRAALVM_HOME/jre/ directoryin the GraalVM package based on JDK 11. This has an impact on the path to the languages location,e.g., $GRAALVM_HOME/jre/languages/js now becomes $GRAALVM_HOME/languages/js):
GraalVM Native Imageon JDK 11 allows usage of all JDK 8 command line options. Currently the nativeimage builder (
$GRAALVM_HOME/bin/native-image) does not support the JavaPlatform Module System (JPMS) and has no module introspection at image run time.
Pease note, at present GraalVM Updater cannot rebuild images (
$GRAALVM_HOME/bin/gu rebuild-images) with GraalVM Enterprise and Community editions on JDK 11. Even if GraalVM Native Image is installed, a user will encounter the following error while rebuilding:
$ $GRAALVM_HOME/bin/gu rebuild-images ruby
Error: rebuild-images utility isnot available.You may need to install "native-image" component.
Please refer to documentation for the details.
A possible workaround is to rebuild images invoking
rebuild-images command directly, e.g.:
Please be informed, to have GraalVM JDK 11 based build on macOS listed by
/usr/libexec/java_home -V you need to:
- extract the GraalVM archive to
ln -s ../Home/lib/jli/libjli.dylibThis issue will be fixed in the next release.
We provide a preview of GraalVM Community Edition on JDK 11 for ARM64architecture. It includes the support for all JVM languages. The support for theother languages should follow soon after. This distribution includes GraalVMNative Image off the shelf to build instantly starting applications whichconsume less memory in ARM64 environments.
There are some known limitations with this distribution at the moment:
nodedo not support runtime code installation (Trufflecompilations). To avoid failing with
java.lang.NullPointerException, disableTruffle compilations with
nodecrash with a
free(): invalid pointererror.
GraalVM 19.3 switched to using the JDK native code instead of manualsubstitutions. For GraalVM Native Image this switch to Java Native Interface(JNI) platform enabled the possibility to provide support for JDK 11 andextended support for Windows OS. It has no impact on startup time or memoryfootprint, and eliminates the need for shipping JDK libraries such as
libsunec.so along with native images that use Java crypto services. GraalVMnow ships with statically linkable version of the JDK libraries.
Note that the
sunec native library of SunEC provider gets statically linkedinto an image if required (see#951). Thus native images do notdepend on the
sunec shared library anymore at runtime. However, if SunECprovider gets statically linked into an image on Linux and macOS the image willdepend on
Support for using GraalVM Native Image with Maven was introduced with theNative Image Maven Plugin. It means auser can build a project and its native image directly with Maven using the
mvnpackage command. As of the GraalVM version 19.3, the Maven
<groupId> for theGraalVM Native Image related artifacts, including the plugin, changed from
To use the plugin make sure GraalVM home is set as your
JAVA_HOME environment and Native Image is installed. Using the plugin without GraalVM is not recommend.
- We have improved
System.arraycopyto eliminate store checks when copying to
Object. That improvement fixes slowdowns (versus C2) on some EclipseCollections benchmarks.
- A performance regression when creating List values in Scala has been fixed bymore optimized inlining.
- Fixed an issue that could prevent a method from being compiled that contains the JSR bytecode produced by older
javacversions (see #1699).
The Node.js runtime available with GraalVM was updated to the 12.10.0 version, which brought some breaking changes.
To provide better compatibility with the ECMAScript specification, some extensions are now disabled by default, some depending on the launcher (
node, or via GraalVM Polyglot Context). This includes the
printErr functions (the
js.print flag), the
global built-in (superseded by
globalThis, use the
js.global-property flag to reenable), or the
performance global property (the
More details can be found in the project changelog on GitHub.
In GraalVM 19.3 clang and other LLVM tools are no longer required to beinstalled for building the GraalVM LLVM runtime. The LLVM toolchain bundled with GraalVM is used.Also the LLVM toolchain is not an “experimental” feature any more and is used by other languages.
For example, save this native code demonstrating the interoperability with Java as a polyglot.c file:
void*arrayType = polyglot_java_type("int");
void*array = polyglot_new_instance(arrayType,4);
int element = polyglot_as_i32(polyglot_get_array_element(array,2));
Now you can compile it using GraalVM drop-in replacement of traditional
$GRAALVM_HOME/jre/languages/llvm/native/bin/clang polyglot.c -o polyglot
Then run the executable (
polyglot) with its dependencies encoded in GraalVM LLVM runtime:
List of features that have also been added:
- Preliminary support for parsing bitcode produced by LLVM 9
- Added intrinsics for pthread thread management functions
- Support for pthreads LLVM bitcode
Refer to the component changelog on GitHub.
- Updated Python standard library to 3.7.4.
- Implemented support for NumPy 1.16.4 and Pandas 0.25.0, that can be installed with:
$ graalpython -m ginstall install numpy
$ graalpython -m ginstall install pandas
- With the help of Weblogic Scripting Team in conversion of Jython into GraalVM Python,added Jython compatibility (enabled with
—python.EmulateJython) that allows importing ofJava classes and catching of Java exceptions in Python the same way Jython allows it.
$ graalpython --jvm --experimental-option --python.EmulateJython
>>>from java.lang importInteger,NumberFormatException
- Added support for basic sockets. Note that SSL is not implemented, thus there is no
- Implemented missing functions and fixed bugs to run various modules (
- Improved performance of Java interoperability, exceptions that do not escape,various C API functions, and the parser. The parser is ~20% faster now, sometimes upto ~40%, the performance in micro benchmarks is 5x faster, micro benchmarks forC API are 5x faster, but there is no change to NumPy performance numbers.
To see a complete list of changes, please refer to the project changelog.
- FastR has been updated to R version 3.6.1.
- In this release, FastR does not ship with GCC runtime libraries. Use the following commands to install the necessary dependencies:
- Ubuntu 18.04 and 19.04:
apt-get install libgfortran3 libgomp1
- Oracle Linux 7:
yum install libgfortran libgomp
- Oracle Linux 8:
yum install compat-libgfortran-48
brew install email@example.com
- Ubuntu 18.04 and 19.04:
- Preview of support for LLVM based execution of R native extensions.
- FastR is configured to use the GraalVM LLVM toolchain to compile the C/C++ and Fortran code of R packages. The resulting binarieswill contain both the native code and the LLVM bitcode. The R packages that are shipped with FastR were also compiledusing the GraalVM LLVM toolchain and their binaries contain the LLVM bitcode.
- FastR loads and runs the R extensions native code by default, but when run with the option
—R.BackEnd=llvm,it will load and run the LLVM bitcode if available. You can use the LLVM backend selectively for specific R packages via
- If you encounter any issues when installing R packages, you can switch back from the GraalVM LLVM toolchainto the native toolchain by running
fastr.setToolchain("native")or by manually editing the
- Fixed memory leaks reported on GitHub.
- Fixed failures when working with large vectors (>1GB).
grepRaw, but only for
A comprehensive list of changes to the Ruby language component is available on GitHub.
The focus has been on improving compatibility with Ruby on Rails applications.Major changes include:
- Compilation of C extensions is now done with an internal LLVM toolchain producing both native code and bitcode. This means more C extensions should compile out of the box and this should resolve most linker-related issues.
- It is no longer necessary to install LLVM for installing C extensions on TruffleRuby.
- It is no longer necessary to install libc++ and libc++abi for installing C++ extensions on TruffleRuby.
- On macOS, it is no longer necessary to install the system headers package (#1417).
- License updated to EPL 2.0/GPL 2.0/LGPL 2.1 like recent JRuby.
sasscnow works due to using the LLVM toolchain (#1753).
- Include executables of default gems, needed for
rails newin Rails 6.
As of version 19.3 GraalVM provides a code coverage command line tool to recordand analyze the source code coverage of a particular execution of code forlanguages implemented with the Truffle framework. Enable it with
—codecoverageoption, for example
js —codecoverage. Visit the tool reference documentation for moreinformation.
- Previously, to view the JFR files you had to install a plugin. Now GraalVM VisualVM contains the viewer in the tool core. Other JFR viewer improvements include new views for Exceptions and GC, improved performance and accuracy.
- The tool is now able to monitor and profile AArch64 Java and Java 13 processes.
- Enabled support for functional breakpoints and memory tools in Chrome Inspector.
VSCode extensions are provided as VSIX packages. GraalVM team created the firstVSIX extension based on Python implementation. The extension installs with
npmpackage manager and upon the extension installation, the user is requested topoint the
PATH environment variable to GraalVM home directory.
- Added new APIs for statement count resource limits:
try(Context context =Context.newBuilder()
- The default temporary directory can now be configured by
getTempDirectory()method of the
FileSysteminterface will return the default temporary directory.
- Added the
org.graalvm.home.Versionversion utility that allows to create, validate and compare GraalVM versions.
- Added support for detecting and mapping polyglot exception values. Exceptions can be detected using
- Added default target type mapping from guest language exceptions to
Proceed to the GraalVM SDK changelog for the complete list of changes.
- Added standard block node for language implementations. The block node usage allows the optimizingruntime to group elements of a block into multiple block compilation units. This optimization may beenabled using
—engine.PartialBlockCompilation(on by default) and configuredusing
- Merged new experimental inlining heuristic. Inlining budgets are now based on Graal IR nodecounts and no longer Truffle Node counts.
- Support boolean literals in Truffle DSL expressions. Use
isFunction(value) == false.
- Added support for temporary files and directories.
- Threads created by the embedder may now be collected by the GC before they canbe disposed. If languages hold onto thread objects exposed via
initializeThreadthey now need to do so with
WeakReference. This avoidsleaking thread instances.
- Added the new execute method to
LoopNode, which allows loops to return values.
To see the full list of changes to the APIs, proceed to theGraalVM Truffle changelog.