What's new in version 0.9.0
The following new features and notable changes from v.0.8.0 are included in this release:
- New binaries and supported environments.
- The idle tuning feature is now supported on Linux running on Power® Systems and IBM Z® Systems.
- A new Garbage Collection (GC) policy is available that performs no housekeeping.
- A command line option is provided to automatically set a larger Java heap size for applications that run in containers.
- You can now specify the maximum Java heap size as a percentage value.
- The shared classes feature now supports nested jar files.
- System dump data can now be read to help diagnose problems on Linux and Windows platforms.
- There are notable changes to the
- There are notable changes to the
Features and changes
Binaries and supported platforms
The following additional OpenJDK binaries that contain the OpenJ9 VM are now available from the AdoptOpenJDK community:
- OpenJDK version 10
- OpenJDK version 8 for 32-bit Windows
- OpenJDK version 8 for x86 64-bit Linux (Large Heap) for Java heaps >57 GB.
Complete platform support information for OpenJ9 can be found in Supported environments
Idle tuning feature
The idle tuning feature in OpenJ9 keeps your memory footprint small by releasing unused memory back to the
operating system. Prior to Eclipse v0.9.0 this feature was available only on Linux x86 architectures with the
gencon garbage collection policy. From v0.9.0, this feature is now available on Linux for IBM POWER® and IBM Z® architectures.
For more information about this feature, see the following command line options, which control this
The following blog post describes the benefits of using this feature: Are you still paying for unused memory when your Java app is idle?
New GC policy
A new GC policy is introduced for JEP 318: Epsilon: A No-Op Garbage Collector.
When this policy is enabled, the Java object heap is expanded in the normal way until the limit is reached, but memory is not reclaimed through garbage collection. When the limit is reached the VM shuts down.
This JEP has a number of use cases including short-lived applications and certain test scenarios.
To enable this policy you can use one of the following options:
Modifying the default Java heap size for applications that run in containers
When using container technology, applications are typically run on their own and do not need to compete for memory. In this release, changes
are introduced to detect when OpenJ9 is running inside a container. If your application is running in a container and
you want the VM to allocate a larger fraction of memory to the Java heap, set the
-XX:+UseContainerSupport option on the command line.
The following table shows the maximum Java heap size that gets set, depending on the memory available:
||Maximum Java heap size|
|Less than 1 GB||50%
|1 GB - 2 GB||
|Greater than 2 GB||75%
The default heap size for containers only takes affect when running in a container environment and when
-XX:+UseContainerSupport is specified,
which is expected to be the default in a future release.
Specifying the maximum Java heap size as a percentage value
OpenJ9 now supports setting the heap size as a percentage of the physical memory. The following OpenJDK options are recognized and can be set for the VM:
To understand how to set these options, see -XX:InitialRAMPercentage / -XX:MaxRAMPercentage.
If your application is running in a container and you have specified
-XX:+UseContainerSupport, as described in Modifying the default Java heap size for applications that run in containers, both the default heap size for containers and the
options are based on the available container memory.
Shared classes support for nested jar files
Changes are made to the
com.ibm.oti.shared API to support nested jar files.
Direct Dump Reader enabled on Linux and Windows
Direct Dump Reader (DDR) support is now enabled for the OpenJ9 VM on all Linux architectures and on Windows. The DDR code enables the VM to read system dump data by using the OpenJ9 Diagnostic Tool
Framework for Java (DTFJ) API or the
jdmpview tool. If you use the Eclipse Memory Analyzer Tool (MAT), you can also analyze OpenJ9 or IBM VMs by installing the DTFJ plugin.
(Install from the Eclipse Help menu; Install New Software > Work with "IBM Diagnostic Tool Framework for Java" > IBM Monitoring and Diagnostic Tools > Diagnostic Tool Framework for Java)
You must use a 32-bit JVM to look at a 32-bit core, and a 64-bit JVM to look at a 64-bit core. This restriction will be fixed in a later version of OpenJ9.
Changes to the
To match the behavior of OpenJDK,
java.lang.String no longer has a count field, which changes the way that
String.subString() works compared to Java 8.
String.subString() now copies the value array. Similarly,
StringBuilder do not share the value array with any
String created by
For performance and compatibility with the new String object layout, the OpenJ9 implementations of
StringBuilder have been deprecated in favor of the OpenJDK implementations.
Changes to the
SharedClassCacheInfo.getCacheJVMLevel() used to return the JVMLEVEL constant that maps to a Java version number, for example JVMLEVEL_JAVA8. This call now returns only the Java version number, for example 10 for Java 10.
Full release information
To see a complete list of changes between Eclipse OpenJ9 V0.8.0 and V0.9.0 releases, see the Release notes.