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
java.lang.String
class. - There are notable changes to the
com.ibm.oti.shared.SharedClassCacheInfo
class. - New JDK 9 features
- New JDK 10 features
Features and changes
Binaries and supported platforms
The following additional OpenJDK binaries that contain the Eclipse 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 version 0.9.0 this feature was available only on Linux x86 architectures with the
gencon
garbage collection policy. From version 0.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
behavior:
- -XX:[+|-]IdleTuningCompactOnIdle
- -XX:[+|-]IdleTuningGcOnIdle
- -XX:IdleTuningMinIdleWaitTime
- -XX:IdleTuningMinFreeHeapOnIdle
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:
Physical memory <size> |
Maximum Java heap size |
---|---|
Less than 1 GB | 50% <size> |
1 GB - 2 GB | <size> - 512M |
Greater than 2 GB | 75% <size> |
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:
-XX:MaxRAMPercentage
-XX:InitialRAMPercentage
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 -XX:MaxRAMPercentage
and -XX:InitialRAMPercentage
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 plug-in.
(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 VM to look at a 32-bit core, and a 64-bit VM to look at a 64-bit core. This restriction will be fixed in a later version of OpenJ9.
Changes to the java.lang.String
class
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, StringBuffer
and StringBuilder
do not share the value array with any String
created by toString()
.
For performance and compatibility with the new String object layout, the OpenJ9 implementations of StringBuffer
and StringBuilder
have been deprecated in favor of the OpenJDK implementations.
Changes to the SharedClassCacheInfo
class
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.
New JDK 9 features
The following features are supported by OpenJ9:
- JEP 102: Process API Updates
- JEP 110: HTTP 2 Client
- JEP 143: Improve Contended Locking
- JEP 193: Variable Handles
- JEP 199: Smart Java Compilation, Phase Two
- JEP 200: The Modular JDK
- JEP 201: Modular Source Code
- JEP 211: Elide Deprecation Warnings on Import Statements
- JEP 213: Milling Project Coin
- JEP 215: Tiered Attribution for javac
- JEP 216: Process Import Statements Correctly
- JEP 217: Annotations Pipeline 2.0
- JEP 219: Datagram Transport Layer Security (DTLS)
- JEP 220: Modular Run-Time Images
- JEP 221: Simplified Doclet API
- JEP 222: jshell: The Java Shell (Read-Eval-Print Loop)
- JEP 223: New Version-String Scheme
- JEP 224: HTML5 Javadoc
- JEP 225: Javadoc Search
- JEP 226: UTF-8 Property Files
- JEP 227: Unicode 7.0
- JEP 229: Create PKCS12 Keystores by Default
- JEP 232: Improve Secure Application Performance
- JEP 235: Test Class-File Attributes Generated by javac
- JEP 236: Parser API for Nashorn
- JEP 238: Multi-Release JAR Files
- JEP 240: Remove the JVM TI hprof Agent
- JEP 241: Remove the jhat Tool
- JEP 244: TLS Application-Layer Protocol Negotiation Extension
- JEP 247: Compile for Older Platform Versions
- JEP 249: OCSP Stapling for TLS
- JEP 251: Multi-Resolution Images
- JEP 252: Use CLDR Locale Data by Default
- JEP 253: Prepare JavaFX UI Controls and CSS APIs for Modularization
- JEP 254: Compact Strings (not enabled by default)
- JEP 255: Merge Selected Xerces 2.11.0 Updates into JAXP
- JEP 256: BeanInfo Annotations
- JEP 257: Update JavaFX/Media to Newer Version of GStreamer
- JEP 258: HarfBuzz Font-Layout Engine
- JEP 259: Stack-Walking API
- JEP 260: Encapsulate Most Internal APIs
- JEP 261: Module System
- JEP 262: TIFF Image I/O
- JEP 263: HiDPI Graphics on Windows and Linux®
- JEP 264: Platform Logging API and Service
- JEP 265: Marlin Graphics Renderer
- JEP 266: More Concurrency Updates
- JEP 267: Unicode 8.0
- JEP 268: XML Catalogs
- JEP 269: Convenience Factory Methods for Collections
- JEP 272: Platform-Specific Desktop Features
- JEP 273: DRBG-Based SecureRandom Implementations
- JEP 274: Enhanced Method Handles
- JEP 275: Modular Java Application Packaging
- JEP 276: Dynamic Linking of Language-Defined Object Models
- JEP 277: Enhanced Deprecation
- JEP 280: Indify String Concatenation
- JEP 282: jlink: The Java Linker
- JEP 283: Enable GTK 3 on Linux
- JEP 285: Spin-Wait Hints
- JEP 287: SHA-3 Hash Algorithms
- JEP 288: Disable SHA-1 Certificates
- JEP 289: Deprecate the Applet API
- JEP 290: Filter Incoming Serialization Data
- JEP 292: Implement Selected ECMAScript 6 Features in Nashorn
- JEP 298: Remove Demos and Samples
- JEP 299: Reorganize Documentation
You can find the full list of features for JDK 9 at the OpenJDK project. Any remaining features that are listed do not apply to OpenJ9.
New JDK 10 features
The following features are supported by OpenJ9:
- JEP 286: Local-Variable Type Inference
- JEP 313: Remove the Native-Header Generation Tool (javah)
- JEP 314: Additional Unicode Language-Tag Extensions
- JEP 319: Root Certificates
- JEP 322: Time-Based Release Versioning
You can find the full list of features for JDK 10 at the OpenJDK project. Any remaining features that are listed do not apply to OpenJ9.
Full release information
To see a complete list of changes between Eclipse OpenJ9 version 0.8.0 and version 0.9.0 releases, see the Release notes.