IBM SDK, Java Technology Edition, Version 8: Supplementary documentation

Java 8 service refresh 6 fix pack 10 (May 2020)

This release includes an update for CVE-2019-2949, from the October 2019 Oracle CPU update, as mentioned in the entry for Java 8 service refresh 6.

Java 8 service refresh 6 fix pack 5 (January 2020)

Concurrent scavenge garbage collection mode now supports Ownable Synchronizers. This update removes the limitation described in Java 8 service refresh 5.

Java 8 service refresh 6 (November 2019)

This release includes the October 2019 Oracle CPU update, with the exception of CVE-2019-2949, as listed in the security bulletin.

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>
   

   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>

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 (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.vm.80.doc/docs/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
• JavaFX application launcher
• Behavior of -Xshareclasses:destroyAll option
• JIT-based GPU limitations

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] Sent forEach in <method name> at line <line number> to CPU based on performance heuristics
  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