IBM Support

IBM SDK, Java Technology Edition, Version 8: Current news

News


Abstract

Support Information for IBM® SDK, Java™ Technology Edition, Version 8 that is not available in the user documentation.

Content

The documentation to support this release is available in the IBM product documentation .

Supplementary information is available for the following code refreshes:


For information about security fixes, see Security Alerts .
For a list of the IBM fixes included, see IBM SDK, Java Technology Edition, Version 8 fixes .
You can download the SDK from the Java SDK developer center .

For information about the daylight saving time changes included in service refreshes and fix pack levels, see Olson time zone updates . Later updates can by applied using the IBM Time Zone Update Utility for Java (JTZU) .

To compare the IBM SDK functionality with Oracle build levels at each service refresh level, see Comparative Oracle build levels .


 

Java 8 service refresh 5 fix pack 31 (March 2019)

This fix pack includes an updated Eclipse OpenJ9 Java virtual machine, which contains the following updates, as described in the Eclipse 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®


 
Java 8 service refresh 5 fix pack 27 (January 2019)

This fix pack includes an updated Eclipse OpenJ9 Java virtual machine, which contains the following update, as described in the Eclipse 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.


 
Java 8 service refresh 5 fix pack 26 (December 2018)

This fix pack includes an updated Eclipse OpenJ9 Java virtual machine, which contains a number of changes. The following information is provided in the Eclipse OpenJ9 user documentation to describe these changes:

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.

 Restriction:

  • 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.


Java 8 service refresh 5 fix pack 21 (September 2018)

Temporary system property for improving JCEPlus performance

Currently, the performance of HMAC in the IBMJCEPlus provider is not as good as in the IBMJCE provider. Until HMAC performance in IBMJCEPlus is optimized further, you can use the following system property to disable HMAC in IBMJCEPlus and instead use the implementation in IBMJCE:    

com.ibm.crypto.plus.provider.DISABLEHMAC = true  

(The default value is false.)


 


Java 8 service refresh 5 fix pack 17 (June 2018)

Dump files cannot be located on SLES 12 systems

On SLES 12 and later, system dump files are no longer created in the users home directory when requested by the JVM. Instead, files with an .xz extension are created in the /var/lib/systemd/coredump/ directory. This behavior is expected because SLES 12 introduces the systemd daemon as a replacement to the System V init daemon, which is not supported by the Eclipse OpenJ9 JVM.

These core dumps can still be read with the Dump viewer tool by following these steps:

  1. Extract the core dump by running tar -xf *.xz, which produces an uncompressed core dump file with no file extension.
  2. To open the dump with dump viewer, specify the following on the command line:
     jdmpview -core <filename>copy to clipboard
    Where <filename> is the extracted core dump file.

If you want to compress the dump, executable files, and libraries into a single .zip file, you can use the jextract utility, and pass this zip file to Dump viewer using the following command:

 jdmpview -zip <filename.zip> copy to clipboard

For more information about jextract and Dump viewer (jdmpview), see  Using the dump viewer .

 


 

Java 8 service refresh 5 fix pack 10 (January 2018)

 

 


Out of memory exceptions when running applications with compressed references enabled

The Oracle CPU for January contains an update for CVE-2018-2582 to fix vulnerabilities in the Hotspot virtual machine (VM) that might be exploited by Java web start applications and applets. Fixes are also applied for the OpenJ9 virtual machine. The fix increases the amount of low memory used for VMs that use compressed references. Customers who are running close to the maximum amount of allowed 32-bit memory might experience out of memory exceptions. A possible workaround is to use the -Xmcrs option to secure space in the lowest 4GB memory area for any native classes, monitors, and threads that are used by compressed references.

For more information about this option, see -Xmcrs .

 

 

 


 


Java 8 service refresh 5 fix pack 5 (November 2017)

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 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 (8.0.5.5) 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, this is configured 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 >64K, the file descriptor count defaults to 64K.
  • If your ulimit value is <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 set, you can configure the value by setting the following environment variable:

 

 

  • export IBM_JAVA_FDLIMIT=<file descriptor count>


where the <file descriptor count> is a value that is less than your system ulimit.

 

 

 

 

 


 


Java 8 service refresh 5 (September 2017)

Support for z/OS v2.3


This update includes support for z/OS v2.3.

Enabling late attach agents to redefine or retransform classes

Although the use of the -XX:[+|-]EnableHCR command-line option is no longer required generally, as described here , you must specify -XX:-EnableHCR if you want to use the -Xjit:enableGPU option.

Limitations with Concurrent Scavenge garbage collection mode

Concurrent scavenge mode aims to minimize the time spent in "stop-the-world" operations by garbage collecting in parallel with running application threads. The following limitations apply:

  • Ownable Synchronizers are not currently supported. As a consequence, the java.lang.management.ThreadInfo.getLockedSynchronizers() API might return an incorrect value.

Increase in thread native stack size on AIX systems

From this refresh, when an application runs in debug mode on AIX the thread native stack size is increased. As a consequence, you might encounter java/lang/StackOverflowError errors.

When a java/lang/StackOverflowError error occurs, the amount of stack space required by the thread exceeds the default stack size set by the operating system or by the VM. By default, the stack size is set to 256 KB. You can determine what value the VM is using by running the -verbose:sizes option.

The -Xmso option controls the native stack size of a thread. If you encounter java/lang/StackOverflowError errors when debugging issues on AIX, use this option to increase the stack size. The size you need might vary depending on your application requirements.

Note that java/lang/StackOverflowError errors can occur for other reasons. For more information, see  Diagnosing a java.lang.StackOverflowError .

IBMPKCS11Impl security provider

The IBM 4765 cryptographic card is supported in a limited fashion on the AIX platform, in both 32-bit and 64-bit modes, for use by Security Key Lifecycle Manager (SKLM).

For SKLM, only the following PKCS#11 crypto operations are supported:

  • Generate an AES 128-bit or 256-bit key.
  • Encrypt and decrypt data using an AES key and an AES/ECB/NoPadding cipher.
  • Store and retrieve an AES key to/from a PKCS11IMPLKS (PKCS#11) key store.


 


Java 8 service refresh 4 fix pack 2 (March 2017)

JIT GPU enabled forEach fails with CUDA version 8


An issue exists with CUDA version 8 when -Xjit:enableGPU is set to enable GPU processing with the Just-In-Time compiler. Attempting to diagnose the problem by using the -Xjit:enableGPU="{enforce|verbose}" option indicates that forEach invocations are failing.

CUDA version 8 is not supported at this time. You must use CUDA version 7.5 instead.

 

 

 


 


Java 8 service refresh 4 fix pack 1 (February 2017)

Security vulnerability CVE-2016-2183


A further fix is added to mitigate against this vulnerability, which is described here . (APAR IV93288)

 

Go back to top

 

 


 


Service refresh 3 fix pack 22 (Dec 2016)

 


-XX:[+|-]EnableHCR

Use the -XX:+EnableHCR option to enable late attached agents to redefine or retransform classes. This option might incur a performance penalty. This option is temporary and deprecated and will be removed in a future update when no longer necessary.

For more information about the Java attach API, see https://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.lnx.80.doc/user/attachapi.html

Note: Unrecognised -XX: options are ignored by default. The -XX:+EnableHCR option will not cause an error after removal.

 

 

 


 


Service refresh 1 fix pack 10 (July 2015)

Partial fix for the behavior of -Xshareclasses:destroyAll

In the initial release, an issue was documented for this option on z/OS platforms. See Behavior of -Xshareclasses:destroyAll .


Following a fix for the 64-bit JVM, the problem remains only on the 31-bit JVM. When the destroyAll option is invoked from a 31-bit JVM, 64-bit caches are not destroyed. The following message is displayed:

 

  • JVMSHRC735I Use a 64-bit JVM to perform the requested operation on the 64-bit shared cache \"cachename\" as the 31-bit JVM cannot verify that the shared memory was created by the JVM

     

 

 


 

Service refresh 1 (May 2015)

 

DumpControlMXBean visible in JConsole

 

The DumpControlMXBean is unintentionally visible in JConsole. Do not use this MXBean to create heap, system, or Java dumps. Instead, use the Health Center tool as described in Triggering Dumps .

 

 


 

Initial release (February 2015)

 

 

 


Segmentation fault in Eclipse

The following segmentation fault might be seen shortly after starting Eclipse:

 

 

  • java: cairo-misc.c:380: _cairo_operator_bounded_by_source: Assertion `NOT_REACHED' failed.


This problem is due to a known issue with the Cairo graphics library that is used by Eclipse. You can work around this problem by adding the following line to the eclipse.ini file after the line for -vmargs:

  -Dorg.eclipse.swt.internal.gtk.cairoGraphics=false

Alternatively, installing a newer version of the operating system or a newer version of Eclipse might resolve the problem.

 

Go back to top

 


JavaFX application launcher

This feature is added in Oracle JEP 153. However, JavaFX is not supported by the IBM SDK, Java Technology Edition, V8. An error occurs if you attempt to run a JavaFX application from the command line.

 

 

Go back to top

 


Behavior of -Xshareclasses:destroyAll

Due to a current issue on z/OS, when the destroyAll option is invoked from a 31-bit Java virtual machine (JVM), 64-bit caches are not removed. Similarly, when the destroyAll option is invoked from a 64-bit JVM, 31-bit caches are not removed. The following message is displayed:


JVMSHRC735I: Use a nn-bit JVM to perform the requested operation on the nn-bit shared cache \"cachename\" as the nn-bit JVM cannot verify that the shared memory was created by the JVM.

 

Go back to top

 


JIT-based GPU limitations

 

  • Known defects
    Using the CUDA4J callback feature together with the -Xjit:enableGPU option might cause Java threads to deadlock or output the message Error 70.

    Unsupported modes
    JIT GPU support is not provided with -Xgcpolicy:balanced.
    Methods that are compiled by the AOT compiler, with the -Xshareclasses option, cannot use GPU.

    Error codes
    If an error condition occurs in a CUDA runtime or CUDA Driver API, the corresponding error code is printed in verbose mode by JIT. To interpret the meaning of the error, refer to the CUDA documentation.

    -Xjit:enableGPU option
    This option contains the following special characters: { | }
    When you use this option on the command line, you might need to enclose the option with quotation marks. For example:
    • java -Xjit:"enableGPU={default|verbose}"

    Generating verbose output
    If you want to include line numbers in the GPU verbose output you must compile your .java file with line numbers included. If you do not include them, the value -1 is printed against each forEach statement.

    JIT GPU behavior
    Not all parallel forEach statements are sent to GPU, for the following reasons:
    • JIT was able to detect a parallel forEach statement and transform it into GPU code, but based on runtime performance heuristics it chose to run forEach on the CPU instead. For example, the range of the stream might be too small to justify sending it to GPU. In this case, if enableGPU={verbose} was specified the following message is displayed:
      • [IBM JIT GPU]
     
      • Note that current heuristics are quite conservative. This behavior can be overridden by using enableGPU={enforce}.
    • JIT was not able to detect forEach or transform it to GPU code. Usually, no verbose message is given in this case. The reasons this could happen include the following possibilities:
      • The method that calls forEach has not executed enough times for it to be compiled by JIT, or the compilation has not finished before the method was invoked again. Because of that, GPU exploitation can usually be observed on methods that run many times.
      • Some simple idioms can be recognized and simplified by JIT. For example, a forEach statement that copies one array into another might be converted into a highly optimized inline code.
      • Currently, JIT handles only simple array updates. For example, the writes to target arrays must be in the following form:

      •  a[i + C] = ...
        • where i is the lambda parameter and C is some lambda invariant expression. This statement should execute unconditionally and only once per modified array.
      • In the case of nested parallel forEach calls, only an inner forEach can be sent to GPU.
      • There might be other scenarios where Java code is too complex to be transformed into GPU code.

 

Go back to top

 

 


 

Comparative Oracle build levels

The following table indicates the Oracle FCS build level that has comparative functionality to the IBM SDK:

 

Release date IBM SDK Oracle Java 8 FCS build
February 2015 Initial release Update 31 Build 12
May 2015 Service refresh 1 Update 45 Build 13
July 2015 Service refresh 1 fix pack 10 Update 51 Build 16
November 2015 Service refresh 2 Update 65 Build 17
January 2016 Service refresh 2 fix pack 10 Update 71 Build 15
April 2016 Service refresh 3 Update 91 Build 14
July 2016 Service refresh 3 fix pack 10 Update 101 Build 13
October 2016 Service refresh 3 fix pack 20 Update 111 Build 14
February 2017 Service refresh 4 fix pack 1 Update 121 Build 13
April 2017 Service refresh 4 fix pack 5 Update 131 Build 11
July 2017 Service refresh 4 fix pack 10 Update 141 Build 15
October 2017 Service refresh 5 fix pack 5 Update 151 Build 12
January 2018 Service refresh 5 fix pack 10 Update 161 Build 12
May 2018 Service refresh 5 fix pack 15 Update 171 Build 11
August 2018 Service refresh 5 fix pack 20 Update 181 Build 12
November 2018 Service refresh 5 fix pack 25 Update 191 Build 26
March 2019 Service refresh 5 fix pack 30 Update 201 Build 09

Go back to top

Document information

More support for: Runtimes for Java Technology

Component: Java SDK

Software version: 8.0

Operating system(s): AIX, Linux, Windows, z/OS

Software edition: Java SE

Reference #: 1672834

Modified date: 01 April 2019