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
- Changes to the Java version output
- IBM J9 virtual machine changes:
- Managing the Java object heap when the JVM is idle (Linux only)
- New garbage collection mode for reduced pause times
- Ability for the JIT compiler to allocate memory higher than the 2 GB bar (z/OS only)
- Tuning the shared classes cache
- Improved MXBean compatibility
- Change in the return value of the OperatingSystemMXBean.getProcessCpuTime() method
- Improved monitoring of memory pools and garbage collection activity
- -XX:[+|-]InterleaveMemory disabled by default (AIX, Linux, and Windows)
- Late attach agents can redefine or retransform classes
- Improved diagnostic information for VM hooks
- Extra page of memory no longer required when using large page sizes (Linux on IBM Z and z/OS only)
- Default value for the initial Java heap size
- -Xthr:<fastNotify|noFastNotify> option
- Some -Xzero sub-options no longer supported
- Attach API exceptions now begin with com.sun
- Runtime Instrumentation facility turned off by default (AIX, Linux, and z/OS only)
- Changes to Strings to support CompactStrings
- Packed object evaluation technology removed
- 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
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
- 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
andnotify
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
- Changes to the Java version information
- Output from the
java -version
command is changed. Here is an example:
The line starting withjava 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
OpenJ9
replaces the linesJ9VM
andJIT
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:
where file_descriptor_count is a value that is less than your systemexport IBM_JAVA_FDLIMIT=file_descriptor_count
ulimit
. - If your
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>)
Service refresh 5 fix pack 15
- 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.
- 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.
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:
- -XX:InitialRAMPercentage (OpenJ9 user documentation)
- -XX:MaxRAMPercentage (OpenJ9 user documentation)
- 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.
Service refresh 5 fix pack 26
- 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
- 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
- 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.
- 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
- 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
- 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.
- 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
orSTDERR
by using the-Xdump
command-line option. See Writing toSTDOUT
/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
- 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
, andtrace
. These options are new:launch
,onthrow
,onuncaught
,mutf8
, andquiet
. For more information about the options for the new JDWP implementation, see the command-line help:java -agentlib:jdwp=help
- 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.