Service refresh 5

This refresh contains significant changes.

Skip to Service refresh 5 fix pack 5.

Skip to Service refresh 5 fix pack 10.

Skip to Service refresh 5 fix pack 15.

Skip to Service refresh 5 fix pack 16.

Skip to Service refresh 5 fix pack 17.

Skip to Service refresh 5 fix pack 20.

Skip to Service refresh 5 fix pack 25.

Skip to Service refresh 5 fix pack 26.

Skip to Service refresh 5 fix pack 27.

Skip to Service refresh 5 fix pack 30.

Skip to Service refresh 5 fix pack 31.

Skip to Service refresh 5 fix pack 35.

Skip to Service refresh 5 fix pack 36.

Skip to Service refresh 5 fix pack 37.

Skip to Service refresh 5 fix pack 40.

Skip to Service refresh 5 fix pack 41.

Service refresh 5

This release includes the following new features:
Java™ version output
The output from the java -version and java -showversion command-line options and the java.version system property are updated to contain the Oracle build number that the IBM SDK is based on. For example, the string 1.8.0_141 indicates that the SDK is based on Oracle SE 1.8 class libraries, update 141 (U141).

The output also contains changes to indicate the Version, Release, Modification, and Fix pack number (V.R.M.F). For example, Java(TM) SE Runtime Environment (build 8.0.5.0 ... reflects Version 8, Service Refresh 5.

Managing the Java object heap when the JVM is idle (Linux® only)
The following tuning options are available to manage the Java object heap when the JVM is idle:
  • The -XX:IdleTuningMinIdleWaitTime option option controls how long the JVM must be idle before the other tuning options take effect.
  • The -XX:[+|-]IdleTuningCompactOnIdle option option controls whether the garbage collector should collect and compact the Java object heap, which improves the use of the heap.
  • The -XX:[+|-]IdleTuningGcOnIdle option option controls whether free memory pages are released to reduce the memory footprint.
  • The -XX:IdleTuningMinFreeHeapOnIdle option option can be used with -XX:+IdleTuningGcOnIdle to set the minimum amount of free memory that should remain in the object heap.

    This option applies only to Linux on x86-32 and x86-64 architectures when the Generational Concurrent (gencon) garbage collection policy is in use. This option is not effective if the object heap is configured to use large pages.

New garbage collection mode for reduced pause times
A new mode is available that works with the Generational Concurrent (gencon) garbage collection policy. When this mode is enabled, the JVM attempts to reduce GC pause-times for response-time sensitive, large heap applications, which improve throughput stability. The mode is controlled by the -Xgc:concurrentScavenge option, which requires a minimum of z/OS® V2R3 (or z/OS V2R2 with APAR OA51643) and z14 hardware, and is supported only for the 64-bit JVM. If the operating system and hardware requirement is not met, the option is ignored.
Ability for the JIT compiler to allocate memory higher than the 2 GB bar (z/OS only)
On z/OS V2R3 systems, residency mode for 64-bit programs (RMODE64) is enabled by default. This feature allows the JIT to allocate executable code caches higher than the 2 GB memory bar. This behavior is the default unless the -Xjit:disableRMODE64 option is specified on the command line. For more information, see disableRMODE64 (z/OS only).
Tuning the shared classes cache
You can now create a soft limit on the contents of the shared classes cache that can be programmatically queried and adjusted by using an MXBean or modified by using command-line options. The ability to monitor and tune the size of the cache can help you reduce footprint and startup time when running multiple similar servers.

If you specify the -Xscmx option as in earlier releases, there is no change in behavior; this option specifies the size of a new shared class cache. However, if you also specify the new -XX:SharedCacheHardLimit option, the -Xscmx option specifies the soft maximum size of the new shared class cache, and the -XX:SharedCacheHardLimit option specifies the actual maximum size. When the soft maximum limit is reached (the cache is soft full), data cannot be added to the cache unless you increase the soft maximum limit. For more information, see -Xscmx option and -XX:SharedCacheHardLimit option.

Improved MXBean compatibility
The monitoring and management interface extensions of the java.lang.mangement APIs are updated for improved compatibility with the following com.sun.management classes.
  • GarbageCollectorMXBean
  • GarbageCollectionNotificationInfo
  • GcInfo
  • OperatingSystemMXBean
  • UnixOperatingSystemMXBean
This compatibility includes class cast compatibility and implementation of the full set of APIs provided by these com.sun.management classes. For more information, see the Language Management API Reference.
If you rely on the output from the earlier interface extensions, the following new options are available to revert to the behavior of that implementation:
  • -Dcom.ibm.lang.management.OperatingSystemMXBean.isCpuTime100ns
  • -XX:[+|-]HeapManagementMXBeanCompatibility
For more information about these options, see Change in the return value of the OperatingSystemMXBean.getProcessCpuTime() method and Improved monitoring of memory pools and garbage collection activity.
Change in the return value of the OperatingSystemMXBean.getProcessCpuTime() method
The OperatingSystemMXBean.getProcessCpuTime() method is changed to return values in nanoseconds instead of hundreds of nanoseconds, for compatibility with the com.sun.management.OperatingSystemMXBean and UnixOperatingSystemMXBean interfaces. You can revert to the previous behavior by using the -Dcom.ibm.lang.management.OperatingSystemMXBean.isCpuTime100ns option system property.
Improved monitoring of memory pools and garbage collection activity
To help you understand the behavior of your application, enhancements are made to the IBM® Garbage Collector and Memory Pool MXbeans. In earlier releases, memory pool information is aggregated and reported for the entire Java heap. In this release, more detailed information can be obtained about memory pools and garbage collector activity for a garbage collection policy.

If your monitoring application is written to expect only one heap memory pool, or relies on the memory pool name Java heap, you can revert to the earlier implementation by using the -XX:+HeapManagementMXBeanCompatibility option. For more information about this option and the new MemoryPool and GarbageCollector names that are provided, see -XX:[+|-]HeapManagementMXBeanCompatibility option.

-XX:[+|-]InterleaveMemory disabled by default (AIX®, Linux, and Windows)
Memory interleaving is now disabled by default. For more information, see -XX:[+|-]InterleaveMemory option (AIX, Linux, and Windows).
Late attach agents can redefine or retransform classes
Late attach agents can redefine or retransform classes by default. You no longer need to use the -XX:+EnableHCR option, described in IBM SDK, Java Technology Edition, Version 8: Supplementary information, to enable this function. For more information about the Java attach API, see Java Attach API in the OpenJ9 user documentation.
Improved diagnostic information for VM hooks
New tracepoints are added that are triggered when the callbacks for a VM hook, such as the class unload hook, exceed a time threshold. When triggered, a new section is produced in the Java dump output. The tracepoints and Java dump provide enough information to identify the callbacks.

For more information about the HOOK section of a Java dump file, see Hook (HOOK) in the OpenJ9 user documentation. For more information about tracepoints, see Tracing Java applications in the J9 VM reference.

Extra page of memory no longer required when using large page sizes (Linux on IBM Z and z/OS only)
You no longer have to allow for another page of memory when specifying an object heap size that is a multiple of a large page size. In earlier releases, if the page size was 2 GB for example, setting -Xmx2G actually used 4 GB of memory. To avoid using more memory, you had to make the heap size a little smaller than an integral number of pages by subtracting at least 16 bytes. For example, for a 2 GB page size, you had to specify a maximum heap size of -Xmx2147483632 (2147483648 minus 16 bytes) instead of -Xmx2048m (2 GB). For a 4 GB page size, you had to specify a heap size of -Xmx4294967280 (4,294,967,296 minus 16 bytes) instead of -Xmx4096m (4 GB), and so on. From this release, you do not have to reduce the heap size.
Default value for the initial Java heap size
The -Xms option sets the initial size of the Java heap. If this option is not set on the command line, the garbage collector sets an initial size of 8 MB by default. In earlier releases of the SDK, the garbage collector sets a default value of 4 MB. For more information about this setting, see -Xms option in the OpenJ9 user documentation.
-Xthr:<fastNotify|noFastNotify> option
You can now use -Xthr:fastNotify to increase the throughput of an application, specifically when regular usage of wait and notify causes a large number of threads to try to acquire a Java monitor. For more information, see -Xthr option in the OpenJ9 user documentation.
Some -Xzero sub-options no longer supported
The j9zip, noj9zip, sharezip, and nosharezip sub-options are no longer supported. If you specify these options, they are parsed but do nothing. For more information about these options, see -Xms option in the OpenJ9 user documentation.
Attach API exceptions now begin with com.sun
Attach API exceptions are now prefixed with com.sun.tools.attach instead of com.ibm.tools.attach.
Runtime Instrumentation facility turned off by default (AIX, Linux, and z/OS only)
In earlier updates, the RI facility was enabled by default on all platforms that support it. The RI facility is now disabled by default. For more information, see -XX:[+|-]RuntimeInstrumentation in the OpenJ9 user documentation.
Changes to Strings to support CompactStrings
In order to support compact Strings (-XX:+CompactStrings), java.lang.String no longer contains an offset field, which is used to indicate the start of the String in the underlying char[] data. Performance might be affected when using the following methods in your code for values of beginIndex other than zero:
  • String.substring(int beginIndex)
  • String.substring(int beginIndex, int endIndex)

In earlier releases, a new String is created but the underlying char[] is shared with the original String so that no char[] data is copied. If performance is significantly degraded because char[] data is now being copied, try re-implementing the code to avoid copying the String data.

Note: Applications that are written to run on Java implementations that use the HotSpot VM are unaffected, because String data is copied, even when using a beginIndex of zero.
Packed object evaluation technology removed
The packed object technology preview is no longer available.

Service refresh 5 fix pack 5

This release contains the latest IBM fixes, the October 2017 Oracle Critical Patch Update (CPU), and the following updates:
Changes to the Java version information
Output from the java -version command is changed. Here is an example:
java version "1.8.0_151"
Java(TM) SE Runtime Environment (build 8.0.5.5 - pxa6480sr5fp5-20171109_02(SR5 FP5))
IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64 Compressed References 20171102_369060 (JIT enabled, AOT enabled)
OpenJ9 - 7ade437
OMR - 1b656cb
IBM - 59c3d96)
JCL - 20171109_01 based on Oracle jdk8u151-b12
The line starting with OpenJ9 replaces the lines J9VM and JIT in the output from earlier refreshes, because these components are now contributed to the Eclipse Foundation under the Eclipse OpenJ9 project.
AIX support
From this refresh and for all future interim fixes (ifixes), the minimum supported level of AIX 6.1 is now TL9. If you are on a lower maintenance level, the use of certain com.ibm.language.management API extensions can result in ProcessorUsageRetrievalException and GuestOSInfoRetrievalException exceptions.
Configuring the open file descriptor count for the Java process
The maximum number of open file descriptors in a process is controlled by the operating system. On UNIX systems, you configure this number by setting the system hard limit or ulimit.
To avoid excessive resource usage during startup processing, the IBM SDK limits the maximum file descriptor count for a Java process to 64K. The following rules apply:
  • If your ulimit value is greater than 64K, the file descriptor count defaults to 64K.
  • If your ulimit value is less than 64K, the file descriptor count matches the ulimit value.
If your application needs a larger number of open file descriptors or the startup performance is affected by the default limit that is set, you can configure the value by setting the following environment variable:
export IBM_JAVA_FDLIMIT=file_descriptor_count
where file_descriptor_count is a value that is less than your system ulimit.

Service refresh 5 fix pack 10

This release contains the latest IBM fixes and the January 2018 Oracle Critical Patch Update (CPU).

Security checking
For the Eclipse OpenJ9 VM, to improve security, the security checks in the following APIs are now enabled by default, when the SecurityManger is enabled:
  • com.ibm.jvm.Dump.JavaDump()
  • com.ibm.jvm.Dump.HeapDump()
  • com.ibm.jvm.Dump.SnapDump()
  • com.ibm.jvm.Log.QueryOptions()
  • com.ibm.jvm.Log.SetOptions(String)
  • com.ibm.jvm.Trace.set(String)
  • com.ibm.jvm.Trace.snap()
  • com.ibm.jvm.Trace.suspend()
  • com.ibm.jvm.Trace.suspendThis()
  • com.ibm.jvm.Trace.resume()
  • com.ibm.jvm.Trace.resumeThis()
  • com.ibm.jvm.Trace.registerApplication(String, String[])
  • com.ibm.jvm.Trace.trace(<any parameters>)
You can disable security checking for these APIs by setting the following system properties on the command line:
  • -Dcom.ibm.jvm.enableLegacyTraceSecurity=false
  • -Dcom.ibm.jvm.enableLegacyDumpSecurity=false
  • -Dcom.ibm.jvm.enableLegacyLogSecurity=false

Service refresh 5 fix pack 15

This release contains the following changes in addition to the latest IBM fixes and the April 2018 Oracle Critical Patch Update (CPU):
Security checking
If a SecurityManager is being used with class data sharing and the running application is calling the com.ibm.oti.shared.SharedClassUtilities APIs getSharedCacheInfo() or destroySharedCache(), you must grant the code calling these APIs the appropriate SharedClassesNamedPermission. For example code, see Support for custom class loaders in the OpenJ9 user documentation.
New MXBean for controlling dump processing
The production of dump and trace diagnostic data can be controlled by the command-line options -Xdump at startup. If you want to change the dump configuration, you must restart the application. To avoid the restart you can use the com.ibm.jvm.Dump applications processing interface (API) to dynamically change the configuration. A new MXBean is now available that calls the Dump API methods so that you can dynamically configure dump while remotely monitoring an application that is running in a remote server or container.
For more information about the configuration options, see the API documentation.
Hardware support
IBM POWER9™ support was added in this refresh, but important fixes, including security fixes, have been made since. If you are using IBM POWER9, you should upgrade to at least fix pack 30.
Operating system support
The following operating systems are now supported:
  • Red Hat® Enterprise Linux (RHEL) 7.5
  • Ubuntu 18.04
Concurrent scavenge mode is now supported for Linux on IBM Z
The -Xgc:concurrentScavenge option is now supported on IBM z14 hardware with RHEL 7.5 and Ubuntu 18.04 at the following levels and configurations:
Operating systems
  • RHEL 7.5 (minimum kernel level 4.14)
  • Ubuntu 18.04
Hypervisors
  • KVM solutions with QEMU 2.10 or later and a minimum host kernel level 4.12
New environment variable to switch between ICONV and Java converters on z/OS
By default, the ICONV utility is used to convert characters from one code page set to another. However, in some instances ICONV converts to a character that is not recognized on certain platforms. For example, ICONV converts the EBCDIC code x'25' (line feed) to Unicode '\u0085' (next line), which causes problems for XML parsers.
The following environment variable can be set to select the Java converter:
USE_JAVA_CONV=1
By default, the environment variable is set to USE_JAVA_CONV=0, which uses the ICONV utility.

Service refresh 5 fix pack 16

Fix pack 16 includes the following new features in the Eclipse OpenJ9 virtual machine:

Extended support for the idle tuning feature
The idle tuning feature in the Eclipse OpenJ9 VM keeps your memory footprint small by releasing unused memory back to the operating system. This feature is now available on Linux for IBM POWER® and IBM Z® in addition to x86 architectures when used with the generational concurrent (gencon) garbage collection policy. For more information about this feature, see the following command-line options (in the OpenJ9 user documentation), which control this behavior:
Change to the default maximum Java heap size for applications that run in a container
When using container technology, applications are typically run on their own and do not need to compete for memory. In this update, changes are introduced to detect when the OpenJ9 VM 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, you can now set the -XX:+UseContainerSupport option on the command line to obtain a larger percentage of available memory. The percentage allocated depends on the container memory limit. For more information, see -XX:[+|-]UseContainerSupport in the OpenJ9 user documentation.

Service refresh 5 fix pack 17

Fix pack 17 includes the following new features in the Eclipse OpenJ9 virtual machine:

New garbage collection policy
A new policy is introduced in the Eclipse OpenJ9 VM that expands the Java heap in the normal way, but does not reclaim memory through garbage collection operations. This mode is useful for short-lived applications where sufficient memory exists to satisfy the runtime requirements. For more information, see -Xgcpolicy:nogc in the OpenJ9 user documentation.
Specifying the maximum Java heap size as a percentage value
The OpenJ9 VM now supports setting the heap size as a percentage of the physical memory. The following Oracle HotSpot options are recognized and can be set for the VM: If your application is running in a container and you have specified -XX:+UseContainerSupport, both the default heap size for containers and the values for these new options are based on the available container memory.
Shared classes support for nested jar files
Changes are made to the com.ibm.oti.shared application programming interface to support nested jar files.

Service refresh 5 fix pack 20

This release contains the latest IBM fixes and the July 2018 Oracle Critical Patch Update (CPU).

Service refresh 5 fix pack 25

This release contains the latest IBM fixes and the October 2018 Oracle Critical Patch Update (CPU).

The documentation to support IBM SDK, Java Technology Edition Version 8 is changed in this refresh. In addition to this SDK guide, and the supporting J9 VM reference, IBM Documentation now contains the Eclipse OpenJ9 VM user documentation. Some material previously found in the J9 VM reference is removed to avoid duplication. Redirection is in place to minimize the impact of this change.

For any new changes to the Eclipse OpenJ9 VM, see the following release notes in the OpenJ9 user documentation:

Service refresh 5 fix pack 26

Fix pack 26 includes the following new features in the Eclipse OpenJ9 virtual machine, as described in the OpenJ9 user documentation:
New class data sharing suboptions

The -Xshareclasses:bootClassesOnly option disables caching of classes that are loaded by non-bootstrap class loaders. This suboption also enables the nonfatal suboption, which allows the VM to start even if there was an error creating the shared classes cache.

The -Xshareclasses:fatal option prevents the VM from starting if there was an error creating the shared classes cache. You might want to enable this suboption when using the -Xshareclasses:bootClassesOnly suboption, to troubleshoot problems when creating the cache.

Container awareness in the OpenJ9 VM is now enabled by default

When using container technology, applications are typically run on their own and do not need to compete for memory. If the VM detects that it is running in a container environment, and a memory limit for the container is set, the VM automatically adjusts the maximum default Java heap size.

In earlier releases, this behavior was enabled by setting the -XX:+UseContainerSupport option. This setting is now the default.

Pause-less garbage collection mode is now available on Linux x86 platforms

Pause-less garbage collection mode is aimed at large heap, response-time sensitive applications. When enabled, the VM attempts to reduce GC pause times. In earlier releases, pause-less garbage collection mode (-Xgc:concurrentScavenge) was available only on IBM z14 hardware. This mode is now available on 64-bit x86 Linux platforms.

Note: The Generational Concurrent (gencon) garbage collection policy must be used. (This is the default policy.)
You can now restrict identity hash codes to non-negative values
OpenJ9 allows both positive and negative identity hashcodes, which can be problematic if your program (incorrectly) assumes hashcodes can only be positive. However, you can now use the -XX:+PositiveIdentityHash option to limit identity hash codes to non-negative values. Because limiting identity hash codes to non-negative values can have an impact on the performance of hash-intensive operations, this option is not enabled by default.
Support for OpenJDK HotSpot options
For compatibility, the following OpenJDK Hotspot options are now supported by OpenJ9:
  • -XX:MaxHeapSize, which is equivalent to the -Xmx option.
  • -XX:InitialHeapSize, which is equivalent to the -Xms option.
IBM_JAVA_OPTIONS is deprecated
The IBM_JAVA_OPTIONS environment variable is deprecated. Instead, use the new OPENJ9_JAVA_OPTIONS environment variable.

Service refresh 5 fix pack 27

Fix pack 27 includes the following new features in the Eclipse OpenJ9 virtual machine, as described in the OpenJ9 user documentation:
Improved flexibility for managing the size of the JIT code cache
The JIT code cache stores the native code of compiled Java methods. By default, the size of the code cache is 256 MB for a 64-bit VM and 64 MB for a 31/32-bit VM. In earlier releases the size of the code cache could be increased from the default value by using the -Xcodecachetotal command-line option. In this release the size can also be decreased by using this option, with a minimum size of 2 MB. The size of the JIT code cache also affects the size of the JIT data cache, which holds metadata about compiled methods. If you use the -Xcodecachetotal option to manage the size of the code cache, the size of the data cache is adjusted by the same proportion.

Service refresh 5 fix pack 30

Fix pack 30 includes the following new features in the Eclipse OpenJ9 virtual machine, as described in the OpenJ9 user documentation:
Improved support for pause-less garbage collection

Concurrent scavenge mode (-Xgc:concurrentScavenge) is now supported on 64-bit Windows operating systems.

Idle tuning is enabled by default when the VM runs in a docker container
In an earlier release, a set of idle-tuning options were introduced to manage the footprint of the Java heap when the OpenJ9 VM is in an idle state. The following two options are now enabled by default when the OpenJ9 VM detects that it is running in a container and that the VM has entered an idle state:
  • -XX:[+|-]IdleTuningGcOnIdle, which runs a garbage collection cycle and releases free memory pages back to the operating system.
  • -XX:[+|-]IdleTuningCompactOnIdle, which compacts the object heap to reduce fragmentation.
By default, the VM is checked every 180 seconds to detect an idle status. To control the wait time between checks, use the -XX:[+|-]IdleTuningMinIdleWaitTime option (OpenJ9 user documentation). To turn off idle detection, set the value to 0.
Changes to default shared classes cache directory permissions (not Windows)
If you do not use the cachDirPerm suboption to specify permissions for a shared classes cache directory, and the cache directory is not the /tmp/javasharedresources default, the following changes apply:
  • When creating a new cache directory, the default permissions are now stricter.
  • If the cache directory already exists, permissions are now unchanged (previously, when a cache was opened using this directory, the permissions would be set to 0777).

For more information, see -Xshareclasses in the OpenJ9 user documentation.

Service refresh 5 fix pack 31

Fix pack 31 includes the following new features in the Eclipse OpenJ9 virtual machine, as described in the OpenJ9 user documentation:
Better diagnostic information for Linux systems that implement control groups
If you use control groups (cgroups) to manage resources on Linux systems, information about CPU and memory limits is now recorded in a Java dump file. This information is particularly important for applications that run in Docker containers, because when resource limits are set inside a container, the Docker Engine relies on cgroups to enforce the settings. If you are getting a Java OutOfMemoryError error because a container limit has been set on the amount of memory available to an application and this allocation is not sufficient, you can diagnose this problem from the Java dump file. You can find the cgroup information in the ENVINFO section.
Writing a Java dump to STDOUT or STDERR
You can now write a Java dump file to STDOUT or STDERR by using the -Xdump command-line option.
Improved support for pause-less garbage collection
Concurrent scavenge mode is now supported on the following platforms:
  • Linux on IBM POWER LE
  • AIX

Service refresh 5 fix pack 35

Fix pack 35 includes the following updates:
Support for the new Japanese era
Support is added for the new era name, Reiwa. For more information about the changes, see Japanese era changes for the IBM SDK, Java Technology Edition.
Support for more operating system versions
Support is added for Red Hat Enterprise Linux (RHEL) version 8 and Windows Server 2019. For lists of supported operating systems, see Supported environments.
Change to the default native stack size on 64-bit z/OS
The default stack size for operating system threads on 64-bit z/OS is changed from 384 KB to the operating system minimum of 1 MB. For more information about this setting, see -Xmso.
Fix pack 35 also includes the following new features and enhancements in the Eclipse OpenJ9 virtual machine, as described in the OpenJ9 user documentation:
New option for ignoring or reporting unrecognized -XX: options
By default, unrecognized -XX: command-line options are ignored, which prevents an application failing to start. You can now use -XX:-IgnoreUnrecognizedXXColonOptions to turn off this behavior, so that unrecognized -XX: options are reported instead. For more information, see -XX:[+|-]IgnoreUnrecognizedXXColonOptions in the OpenJ9 user documentation.
Writing a Java dump to STDOUT or STDERR

You can now write a Java dump file to STDOUT or STDERR by using the -Xdump command-line option. See Writing to STDOUT/STDERR in the OpenJ9 user documentation for details.

Better diagnostic information for Linux systems that implement control groups

If you use control groups (cgroups) to manage resources on Linux systems, information about CPU and memory limits is now recorded in a Java dump file. This information is particularly important for applications that run in Docker containers, because when resource limits are set inside a container, the Docker Engine relies on cgroups to enforce the settings. If you are getting a Java OutOfMemoryError error because a container limit has been set on the amount of memory available to an application and this allocation is not sufficient, you can diagnose this problem from the Java dump file. You can find the cgroup information in the ENVINFO section. For sample output, see Java dump (ENVINFO) in the OpenJ9 user documentation.

Improved support for pause-less garbage collection

Concurrent scavenge mode (-Xgc:concurrentScavenge) is now supported on AIX and Linux on POWER.

New OpenJ9 option to prevent a network query being used to determine host name and IP address

By default, a network query is used to determine the host name and IP address for troubleshooting purposes. To avoid your program waiting to time out if a nameserver cannot be contacted, you can now prevent the query from being performed. For more information, see -XX:[+|-]ReadIPInfoForRAS in the OpenJ9 user documentation.

New experimental option to improve the performance of JVMTI watched fields
The -XX:[+|-]JITInlineWatches option (OpenJ9 user documentation) is introduced in this release. When enabled, the option turns on experimental JIT operations that are intended to improve the performance of JVMTI watched fields. This option is currently supported only on x86 platforms (Windows, macOS, and Linux).
Change to the default native stack size on 64-bit z/OS
The default stack size for operating system threads on 64-bit z/OS is changed from 384 KB to 1 MB. For more information about this setting, see -Xmso.

Service refresh 5 fix pack 36

Fix pack 36 includes the following new features and changes in the Eclipse OpenJ9 virtual machine, as described in the OpenJ9 user documentation:

Changes to the shared classes cache generation number

On all platforms, the format of classes that are stored in the shared classes cache is changed, which causes the JVM to create a new shared classes cache, rather than re-creating or reusing an existing cache. To save space, all existing shared caches can be removed unless they are in use by an earlier release.

Service refresh 5 fix pack 37

Fix pack 37 includes the following new features and changes in the Eclipse OpenJ9 virtual machine, as described in the OpenJ9 user documentation:

Improved platform support for pause-less garbage collection

Support for concurrent scavenge mode is now extended to z/OS and Linux on IBM Z.

Support for Transparent HugePage

The VM now supports the allocation of huge pages on Linux when you use the madvise setting. To enable this feature, specify the -XX:+TransparentHugePage option on the command line when you start your application.

-XX:[+|-]JITInlineWatches option supported on z/OS and Linux on IBM Z, and enabled by default

This option, introduced in an earlier release, turns on experimental JIT operations that are intended to improve the performance of JVMTI watched fields. The option is now supported on z/OS and Linux on IBM Z, and is enabled by default.

Support for OpenJDK HotSpot options

The -XX:OnOutOfMemoryError OpenJDK Hotspot option is now supported for compatibility.

Removal of -Xdiagnosticscollector option

This option was redundant and has now been removed.

Service refresh 5 fix pack 40

Fix pack 40 includes the following updates:
JDWP implementation replaced with OpenJDK equivalent
JDWP is used to debug Java applications, for example as mentioned in Standard options, and Java Virtual Machine Tool Interface in the OpenJ9 documentation. The previous implementation of JDWP is now replaced with the OpenJDK equivalent. This change removes an issue with the previous implementation and increases alignment with open source software. Because these two implementations are different, the options that are available are also different. These options no longer exist: version, src, log, and trace. These options are new: launch, onthrow, onuncaught, mutf8, and quiet. For more information about the options for the new JDWP implementation, see the command-line help:
java -agentlib:jdwp=help
Fix pack 40 also includes the following new features and changes in the Eclipse OpenJ9 virtual machine, as described in the OpenJ9 user documentation:
Automatically setting an initial heap size
The VM can now learn and set an appropriate initial heap size for an application as an alternative to a user manually sizing and setting an -Xms value. The VM records the size of the heap when startup processing ends, writing this data to the shared classes cache. An average value is set over a few restarts, helping to ensure that the value used for the initial heap size is as accurate as possible. The heap size recorded is specific to the application command line, therefore a different hint is stored for every unique command line.

To turn on this behavior, set the -XX:+UseGCStartupHints option on the command line when you start your application.

Heuristics for compaction during idle GC
The VM now automatically compacts the heap when certain triggers are met during idle garbage collection. As a result of this change, the -XX:[+|-]IdleTuningCompactOnIdle option is deprecated.
Change in behavior of -XX:IdleTuningCompactOnIdle
The -XX:[+|-]IdleTuningCompactOnIdle option is now no longer effective when the -XX:+IdleTuningGcOnIdle option is not specified.
Internal interface changes
Attach API internal interfaces are changed slightly, affecting the SDK's internal class library and the tools.jar and healthcenter.jar files.
  • If an application uses a private copy of the tools.jar file from an earlier release, the application might be unable to use the attach API in this release because the Java classes do not match. Use the tools.jar file from this release instead.
  • Similarly, the healthcenter.jar file from this release is not compatible with earlier releases.

Service refresh 5 fix pack 41

Fix pack 41 includes the following new features and changes in the Eclipse OpenJ9 virtual machine, as described in the OpenJ9 user documentation:

Automatic setting of initial heap size is enabled by default
The -XX:[+|-]UseGCStartupHints option, which, when enabled, turned on the automatic learning and setting of an appropriate heap size for an application, is now enabled by default.
Option to share VM anonymous classes
In earlier releases, anonymous classes, those created by Unsafe.defineAnonymousClass, were not stored in the shared classes cache. These classes are now stored there by default, which means they are available for ahead-of-time (AOT) compilation, potentially improving startup performance. A new option, -XX:[+|-]ShareAnonymousClasses, is introduced that enables you to stop anonymous classes being stored in the shared classes cache.
Performance improvements for JVMTI watched fields on Power Systems
The -XX:[+|-]JITInlineWatches option, which turns on JIT operations to improve the performance of JVMTI watched fields, is now also supported on AIX and Linux on Power Systems.
Linux on x86: Support for Transparent Huge Pages (THP)
When you use the madvise (/sys/kernel/mm/transparent_hugepage/enabled) setting on Linux on x86 systems, THP is now enabled by default. To disable this feature, set -XX:-TransparentHugePage on the command line when you start your application. The THP setting on other systems remains disabled by default when you use madvise, but can be enabled by setting -XX:+TransparentHugePage.
Changes to the shared classes cache generation number
The format of classes that are stored in the shared classes cache is changed, which causes the JVM to create a new shared classes cache rather than re-creating or reusing an existing cache. To save space, you can remove all existing shared caches unless they are in use by an earlier release. As a result of the format change, a layer column now appears in the output of the -Xshareclasses:listAllCaches option. This change is to support a future enhancement.