19.0.2
(2019-06-13)
This is a bug fix release for 19.0 and we recommend upgrading for all 19.0.x users.
Java
- Improved compilation performance of scheduler phase.
- Support retrieving annotations from class initializers (see 1320).
- Fixed problems related to the freetype library: 1269, 1270, 1305.
- Fixed Version string reporting (it was missing
64-Bit
in the string).
Native image
- Fixed
IllegalArgumentException: Cannot create Method for class initializer
(see 1320). - Fixed an issue when the build would loop forever if
META-INF/native-image/native-image.properties
contains—force-fallback
. - Fixed the issue where fallback image generation would not respect the
—no-server
argument. - Fix
native-image-agent=restrict
configuration detection. - Added
-agentlib:native-image-agent=build
configuration option.
LLVM interpreter
Allow LLVM interpreter Context to run without allowIO(true)
.
19.0.0
(2019-05-09)
Early Adopter Windows Support
The early adopter builds for Windows are available for GraalVM. These includethe JDK with the GraalVM compiler enabled, the Native Image capabilities,GraalVM’s JavaScript engine and the developer tools: Chrome inspector baseddebugger, Profiler etc.. Currently there is no gu
utility or the ability toadd support for the other GraalVM languages.
Java
- We updated the base JDK to 8u212. You can find the JDK release notes at the Oracle Technology Network website.
Native Image
Native Image was extracted from the base GraalVM distribution. Currently it isavailable as an early adopter plugin. To install it, run: gu installnative-image
. After this additional step, the native-image
executable will bein the bin
directory, as for the previous releases.
There was a change in how classes are initialized in a native-image
. Now, we initialize application classes at run time by default. The policy for initialization is as follows:
- All JDK classes are initialized at build time.
- We prove the safety of application static initializers after the analysis and initialize the safe classes.
- We provide the following flags to control class initialization in a fine-grained way:
—initialize-at-build-time
and—initialize-at-run-time
.
The performance and startup impact of this change is negligible on all benchmarks that we have.
This change was made to improve user experience: there is no need to writesubstitutions and to deal with instances of unsupported classes ending up in theimage heap. Their applications, given the right configuration for reflection,proxies, etc., should work without performance degradation.
To allow framework authors and end users to keep the startup time at minimum weimproved functionality of —initialize-at-build-time
and—initialize-at-run-time
. These flags allow to specify a policy for wholepackages or individual classes. For example, if we have classes p.C1
, p.C2
,… , p.Cn
, we can eagerly initialize this package with—initalize-at-build-time=p
. If we want to delay one of the classes in packagep
we can simply add —initialize-at-run-time=p.C1
.
The whole class hierarchy can be initialized at build time by simply passing —initalize-at-build-time
on the command line.
We also introduced the flag -H:+PrintClassInitialization
which allows you to track what class initialization does during the image build. This flag will help you configure the build to work as intended.
What should I do if I am a library author?
- To get your tests back in check you can use
—intialize-at-build-time
which will revert to the previous behaviour. - Then use the flag
-H:+PrintClassInitialization
to see when classes get initialized. Based on this output you can make the proper configuration. - Configure your
native-image.properties
by passing—intialize-at-build-time=<csv-of-classes-or-packages>
to it. - Submit a pull request to the downstream libraries with the configuration you believe works well. That way your
native-image.properties
will be concerned only with the classes from your framework. - There is a known issue with lambdas being initialized at build time. If your lambda inherits an interface with a default method and static fields, those fields will get pulled into the image. We will provide a fix to this bug in the next two weeks.
JavaScript
- Fixed various bugs that address compilation problems.
R
- Fixed a fatal error on Linux platforms when sending
SIGINT
during long computations. - Fixed issues with the installation to protected locations: the default Renviron file sets the
R_LIBS_USER
to a directory inside the current user’s home. Users still have to create this directory manually. Alternatively, theconfigure_fastr
script creates the directory, but for the current user only. - Implemented missing C API:
S_realloc
.
Ruby
- Various bug fixes. Most notably fixes around OpenSSL C extension compilation.
- Renamed methods in the
TruffleRuby
object.
Ideal Graph Visualizer (IGV)
- Fixed the issue with the ASTs and call trees not showing up.