19.3.0.2

(2019-12-24)

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 DynamicProxySupport being not thread safe when DynamicProxySupport.addProxyClass is called from multiple threads (see #1927).
  • Resolved a problem leading to a wrong execution of the code produced with the GraalVM native-image builder at optimization level 2 -H:Optimize=2 (see #1995).
  • Fixed a problem when JavaFX applications misbehave with GraalArithmeticStubs (see #1867).
  • Resolved an issue of VM crashing when run with Serial GC (see #1892).
  • ReduceInitialCardMarks is unsafe with OptBulkAllocation in JDK 11 (see #1915).
  • Fixed a transient crash while building native images with GraalVM based on JDK11 (see #1906).

19.3.0

(2019-11-19)

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.

GraalVM JDK 11 Based Builds

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 19.3.x - 图1

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:

  1. $ $GRAALVM_HOME/bin/gu rebuild-images ruby
  2. Error: rebuild-images utility is not available. You may need to install "native-image" component.
  3. Please refer to documentation for the details.

A possible workaround is to rebuild images invoking rebuild-images command directly, e.g.:

  1. $GRAALVM_HOME/bin/rebuild-images ruby

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 /Library/Java/JavaVirtualMachines/ location
  • mkdir /Library/Java/JavaVirtualMachines/graalvm-ce-java11-19.3.0/Contents/MacOS
  • cd /Library/Java/JavaVirtualMachines/graalvm-ce-java11-19.3.0/Contents/MacOS
  • ln -s ../Home/lib/jli/libjli.dylibThis issue will be fixed in the next release.

GraalVM JDK 11 on ARM64

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:

  • npm and node do not support runtime code installation (Trufflecompilations). To avoid failing with java.lang.NullPointerException, disableTruffle compilations with npm —vm.Dgraal.TruffleCompilation=false or node—vm.Dgraal.TruffleCompilation=false.
  • npm and node crash with a free(): invalid pointer error.

Native Image

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 aslibsunec.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 libstdc++.

Native Image Maven Plugin

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 fromcom.oracle.substratevm to org.graalvm.nativeimage:

  1. <plugin>
  2. <groupId>org.graalvm.nativeimage</groupId>
  3. <artifactId>native-image-maven-plugin</artifactId>
  4. <version>19.3.0</version>
  5. <executions>
  6. <execution>
  7. <goals>
  8. <goal>native-image</goal>
  9. </goals>
  10. <phase>package</phase>
  11. </execution>
  12. </executions>
  13. <configuration>
  14. <skip>false</skip>
  15. <buildArgs>
  16. --no-fallback
  17. </buildArgs>
  18. </configuration>
  19. </plugin>

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.

GraalVM Compiler

  • We have improved System.arraycopy to eliminate store checks when copying toObject[]. 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 javac versions (see #1699).

JavaScript

The Node.js runtime available with GraalVM was updated to the 12.10.0 version, which brought some breaking changes.

Additional proposals for ECMAScript 2020 have been implemented (Promise.allSettled and Nullish coalescing) and are available in ECMAScript 2020 mode (—js.ecmascript-version=2020).

To provide better compatibility with the ECMAScript specification, some extensions are now disabled by default, some depending on the launcher (js, node, or via GraalVM Polyglot Context). This includes the print and 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 js.performance flag).

More details can be found in the project changelog on GitHub.

LLVM Interpreter

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:

  1. #include <stdio.h>
  2. #include <polyglot.h>
  3. int main() {
  4. void *arrayType = polyglot_java_type("int[]");
  5. void *array = polyglot_new_instance(arrayType, 4);
  6. polyglot_set_array_element(array, 2, 42);
  7. int element = polyglot_as_i32(polyglot_get_array_element(array, 2));
  8. printf("%d\n", element);
  9. return element;
  10. }

Now you can compile it using GraalVM drop-in replacement of traditional clang:

  1. $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:

  1. lli polyglot

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.

Python

  • 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:
  1. $ graalpython -m ginstall install numpy
  2. $ 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.
  1. $ graalpython --jvm --experimental-option --python.EmulateJython
  2. >>> import sun.misc.Signal
  3. >>> from java.lang import Integer, NumberFormatException
  4. >>> try:
  5. ... Integer.parseInt("99", 8)
  6. ... except NumberFormatException as e:
  7. ... pass
  • Added support for basic sockets. Note that SSL is not implemented, thus there is no https yet:
  1. import urllib.request
  2. print(urllib.request.urlopen("http://google.com").read())
  • Implemented missing functions and fixed bugs to run various modules (timeit, socket, pytest).
  • 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.

R

  • 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
    • MacOS: brew install gcc@4.9
  • 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 —R.BackEndLLVM=pkg1,pkg2.
    • 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 $FASTR_HOME/etc/Makeconf file.
  • Fixed memory leaks reported on GitHub.
  • Fixed failures when working with large vectors (>1GB).
  • Implemented grepRaw, but only for fixed=T.

We encourage the users to experiment with the new LLVM support and report anyissues to GitHub. To see thecomplete list of changes, please refer to the projectchangelog.

Ruby

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.
  • Installing sassc now works due to using the LLVM toolchain (#1753).
  • Include executables of default gems, needed for rails new in Rails 6.

Tools

Code Coverage Command Line Tool

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.

GraalVM VisualVM

  • 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.

Debugger

  • Enabled support for functional breakpoints and memory tools in Chrome Inspector.

Visual Studio Code Extensions

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.

Changes for GraalVM Embedders (SDK)

  • Added new APIs for statement count resource limits:
  1. ResourceLimits.newBuilder()
  2. ResourceLimits.newBuilder()
  3. .statementLimit(1000, null)
  4. .build();
  5. Duration.ofMillis(10))
  6. .statementLimit(1000, null)
  7. .build();
  8. try (Context context = Context.newBuilder()
  9. .resourceLimits(limits).build()) {
  10. context.eval("js", "while(true);");
  11. assert false;
  12. } catch (PolyglotException e) {
  13. assert e.isCancelled();
  14. }
  • The default temporary directory can now be configured by FileSystem. A getTempDirectory()method of the FileSystem interface will return the default temporary directory.
  • Added the org.graalvm.home.Version version utility that allows to create, validate and compare GraalVM versions.
  • Added support for detecting and mapping polyglot exception values. Exceptions can be detected using Value.isException().
  • Added default target type mapping from guest language exceptions to PolyglotException.

Proceed to the GraalVM SDK changelog for the complete list of changes.

Changes for GraalVM Language or Tool Implementers (Truffle)

  • 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 —engine.PartialBlockCompilationSize (default 3000).
  • 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 true or false in expressions,e.g. 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 viainitializeThread they 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.