Expand or collapse sidebar Expand or collapse sidebar

19.3.6

(2021-04-20)

GraalVM Community Edition 19.3.6 is a Critical Patch Update (CPU) release. It is based on OpenJDK CPU and includes all the OpenJDK security fixes released as part of that CPU. It is a full distribution and supersedes the previous release of GraalVM Community Edition 19.3.x. Please note that this is the last release of GraalVM Community Edition 19.3.x.

It also includes:

19.3.5

(2021-01-19)

GraalVM Community Edition 19.3.5 is a Critical Patch Update (CPU) release. It is based on OpenJDK CPU and includes all the OpenJDK security fixes released as part of that CPU. It is a full distribution and supersedes the previous releases of GraalVM 19.3.x.

It also includes the following:

19.3.4

(2020-11-03)

GraalVM Community Edition 19.3.4 is a Critical Patch Update (CPU) and contains fixes to security vulnerabilities and critical bugs. GraalVM Community Edition 19.3.4 is based on OpenJDK CPU and includes all the OpenJDK security fixes released as part of that CPU. It is a full distribution and supersedes all previous releases of GraalVM 19.3. contains

Other changes that went into the release:

19.3.3

(2020-08-04)

GraalVM Community Edition 19.3.3 is a Critical Patch Update (CPU) and contains fixes to security vulnerabilities and critical bugs. GraalVM Community Edition 19.3.3 is based on OpenJDK CPU and will include all the OpenJDK security fixes released as part of that CPU. It is a full distribution and supersedes all previous releases of GraalVM 19.3.

Other changes that went into the release:

19.3.2

(2020-05-12)

GraalVM Community Edition 19.3.2 is a Critical Patch Update (CPU) that only contains security and bug fixes, and supersedes all previous releases of GraalVM 19.3.

The release includes:

  • Java update to 8u252 for Java 8-based GraalVM, please see [OpenJDK 8u252 Release notes]https://adoptopenjdk.net/release_notes.html#jdk8u252).
  • Java update to 11.0.7 for Java 11-based GraalVM, please see OpenJDK 11.0.7 Release notes.

Other critical bug fixes that went into this version:

  • Made Chrome debugger call getter functions several times to test for side-effects.
  • Fixed a problem when LLVM context could send user directory information into the image heap by not caching System.getenv() for a single usage.
  • Substitute missing native methods in DynamicHub with @Delete (see #2054).
  • Added tests for JNI getFieldID and getMethodID method to ensure the class is initialized.

19.3.1

(2020-01-14)

This is a Critical Patch Update (CPU) for GraalVM Enterprise and Community Editions. The 19.3.1 release contains fixes to security vulnerabilities, critical bugs, and other fixes as identified in the January 2020 Oracle Critical Patch Update Advisory. Oracle GraalVM Enterprise Edition 19.3.1 includes all the Java security fixes released as part of that CPU.

The 19.3.1 version also includes the following:

For more information about Oracle Critical Patch Updates and Security Alerts, please visit the announcements list.

Please note that for GraalVM Enterprise Edition on Java 11, java -version incorrectly reports a version based on 11.0.6+1 where as it is actually 11.0.6+8. This issue in the GraalVM build process will be remedied in future releases.

Listed below are issues addressed in this release:

  • Resolved the issue of NullPointerException being thrown with SecurityServicesFeature when the application uses non-JDK related services (#1893).
  • Made efforts to turn Code coverage command line tool more reliable (#1800).
  • Prevented linking errors in Unsafe and ClassLoader by substituting all native methods (#1920).
  • Made dynamically generate On_Load_* function call for static libraries so all libraries are known before the image generation to prevent -Djava.net.preferIPv6Addresses=true returning an incorrect value (#1937).
  • Fixed ProcessHandle properties not providing useful values when running a native image (#2001).
  • Fixed an unsynchronized java.util.WeakHashMap.get access when single engine is shared between several thread local polyglot contexts (#1916).
  • Fixed an issue of JDK 11 GraalVM build not being recognized by macOS /usr/libexec/java_home -V (#801).
  • Implemented a new C APIs used by JSON 2.3.0 (#1857).
  • Ensured that GraalVM Native Image does not have references to native methods from java.lang.reflect.Proxy (#1971).
  • Ensured that all native methods of core classes would be substituted to prevent reflection configuration issues (#1848).
  • Fixed an issue leading to JavaFX applications misbehave with GraalArithmeticStubs (#1867).
  • Ensured that DynamicProxySupport classes being called from multiple threads are thread safe (#1927).
  • Prevent static field values changing during a native image generation (#1945).
  • Fixed the issue with the native linking step at image writing phase when the image uses functions from unsupported static JDK libraries (#1875).

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 Medium-Term Support (MTS) release built from the main line of the project. This is also a major feature release and it is a recommended upgrade to it. The MTS status assures that stability, security, and performance fixes will be backported from the current branch for the next 18 months.

GraalVM JDK 11 Based Builds

With the major update to the 19.3 version, we announce the first release of GraalVM based on JDK 11! This represents a substantial milestone given the differences between JDK 8 and JDK 11. In particular, the Java Platform Module System (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 the JDK changes since JDK 8. These are detailed in the release notes for JDK 9, JDK 10 and JDK 11.

In terms of languages, GraalVM on JDK11 supports all JVM languages (Java, Scala etc.) as well as all guest languages currently supported in GraalVM on JDK8. Due to the modular structure of the base JDK, there is no more $JAVA_HOME/jre/ directory in the GraalVM package based on JDK 11. This has an impact on the path to the languages location, e.g., $JAVA_HOME/jre/languages/js now becomes $JAVA_HOME/languages/js):

Package Comparison

GraalVM Native Image on JDK 11 allows usage of all JDK 8 command line options. Currently the native image builder ($JAVA_HOME/bin/native-image) does not support the Java Platform Module System (JPMS) and has no module introspection at image run time.

Pease note, at present GraalVM Updater cannot rebuild images ($JAVA_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:

$ $JAVA_HOME/bin/gu rebuild-images ruby
Error: rebuild-images utility is not 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.:

$JAVA_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:

  1. extract the GraalVM archive to /Library/Java/JavaVirtualMachines/ location
  2. mkdir /Library/Java/JavaVirtualMachines/graalvm-ce-java11-19.3.0/Contents/MacOS
  3. cd /Library/Java/JavaVirtualMachines/graalvm-ce-java11-19.3.0/Contents/MacOS
  4. ln -s ../Home/lib/jli/libjli.dylib

This 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 ARM64 architecture. It includes the support for all JVM languages. The support for the other languages should follow soon after. This distribution includes GraalVM Native Image off the shelf to build instantly starting applications which consume 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 (Truffle compilations). To avoid failing with java.lang.NullPointerException, disable Truffle 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 manual substitutions. For GraalVM Native Image this switch to Java Native Interface (JNI) platform enabled the possibility to provide support for JDK 11 and extended support for Windows OS. It has no impact on startup time or memory footprint, and eliminates the need for shipping JDK libraries such as libsunec.so along with native images that use Java crypto services. GraalVM now ships with statically linkable version of the JDK libraries.

Note that the sunec native library of SunEC provider gets statically linked into an image if required (see #951). Thus native images do not depend on the sunec shared library anymore at runtime. However, if SunEC provider gets statically linked into an image on Linux and macOS the image will depend on libstdc++.

Native Image Maven Plugin

Support for using GraalVM Native Image with Maven was introduced with the Native Image Maven Plugin. It means a user can build a project and its native image directly with Maven using the mvn package command. As of the GraalVM version 19.3, the Maven <groupId> for the GraalVM Native Image related artifacts, including the plugin, changed from com.oracle.substratevm to org.graalvm.nativeimage:

<plugin>
    <groupId>org.graalvm.nativeimage</groupId>
    <artifactId>native-image-maven-plugin</artifactId>
    <version>19.3.0</version>
    <executions>
        <execution>
            <goals>
                <goal>native-image</goal>
            </goals>
            <phase>package</phase>
        </execution>
    </executions>
    <configuration>
        <skip>false</skip>
        <buildArgs>
            --no-fallback
        </buildArgs>
    </configuration>
</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 to Object[]. That improvement fixes slowdowns (versus C2) on some Eclipse Collections benchmarks.
  • A performance regression when creating List values in Scala has been fixed by more 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 be installed 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:

#include <stdio.h>
#include <polyglot.h>

int main() {
    void *arrayType = polyglot_java_type("int[]");
    void *array = polyglot_new_instance(arrayType, 4);
    polyglot_set_array_element(array, 2, 42);
    int element = polyglot_as_i32(polyglot_get_array_element(array, 2));
    printf("%d\n", element);
    return element;
}

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

$JAVA_HOME/jre/languages/llvm/native/bin/clang polyglot.c -o polyglot

Then run the executable (polyglot) with its dependencies encoded in GraalVM LLVM runtime:

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:
$ 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 of Java classes and catching of Java exceptions in Python the same way Jython allows it.
$ graalpython --jvm --experimental-option --python.EmulateJython
>>> import sun.misc.Signal
>>> from java.lang import Integer, NumberFormatException
>>> try:
...   Integer.parseInt("99", 8)
... except NumberFormatException as e:
...   pass
  • Added support for basic sockets. Note that SSL is not implemented, thus there is no https yet:
import urllib.request
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 up to ~40%, the performance in micro benchmarks is 5x faster, micro benchmarks for C 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 binaries will contain both the native code and the LLVM bitcode. The R packages that are shipped with FastR were also compiled using 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 toolchain to 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 any issues to GitHub. To see the complete list of changes, please refer to the project changelog.

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 record and analyze the source code coverage of a particular execution of code for languages implemented with the Truffle framework. Enable it with --codecoverage option, for example js --codecoverage. Visit the tool reference documentation for more information.

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 first VSIX extension based on Python implementation. The extension installs with npm package manager and upon the extension installation, the user is requested to point the PATH environment variable to GraalVM home directory.

Changes for GraalVM Embedders (SDK)

  • Added new APIs for statement count resource limits:
ResourceLimits.newBuilder()
ResourceLimits.newBuilder()
    .statementLimit(1000, null)
    .build();
              Duration.ofMillis(10))
    .statementLimit(1000, null)
.build();

try (Context context = Context.newBuilder()
                .resourceLimits(limits).build()) {
    context.eval("js", "while(true);");
    assert false;
} catch (PolyglotException e) {
    assert e.isCancelled();
}
  • 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 optimizing runtime to group elements of a block into multiple block compilation units. This optimization may be enabled using --engine.PartialBlockCompilation (on by default) and configured using --engine.PartialBlockCompilationSize (default 3000).
  • Merged new experimental inlining heuristic. Inlining budgets are now based on Graal IR node counts 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 can be disposed. If languages hold onto thread objects exposed via initializeThread they now need to do so with WeakReference. This avoids leaking 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 the GraalVM Truffle changelog.

Connect with us