J9 issues and limitations

Known issues or limitations that you might encounter in specific system environments, or configurations.

System dumps cannot be found on SLES 12 (Linux only)

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:

Extract the core dump by running tar -xf *.xz, which produces an uncompressed core dump file with no file extension.
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 by using the following command:

jdmpview -zip <filename.zip>

For more information about dump viewer (jdmpview), see Dump viewer in the OpenJ9 user documentation.

Change in default page size increases memory usage (AIX only)

The heap is allocated with 64K pages by default, instead of 4K pages. This change improves application throughput and startup performance. However, the change might cause a slight increase in the amount of memory used by your application. If memory usage is critical to your application, follow both these steps to revert to 4K pages:

Set the environment variable LDR_CNTRL=TEXTPSIZE=4K@DATAPSIZE=4K@STACKPSIZE=4K. For more information about this environment variable, see Configuring your system in the OpenJ9 user documentation.
Use the option -Xlp4K. For more information about the -Xlp option, see -Xlp in the OpenJ9 user documentation.

The change has no affect if you are already using the -Xlp option to allocate the heap with large pages.

ThreadMXBean Thread User CPU Time limitation (Linux and z/OS only)

There is no way to distinguish between user mode CPU time and system mode CPU time on this platform. ThreadMXBean.getThreadUserTime(), ThreadMXBean.getThreadCpuTime(), ThreadMXBean.getCurrentThreadUserTime(), and ThreadMXBean.getCurrentThreadCpuTime() all return the total CPU time for the required thread.

On z/OS® ,you can get the CPU time only for the current thread by calling ThreadMXBean.isCurrentThreadCpuTimeSupported(). Calling ThreadMXBean.isThreadCpuTimeSupported() returns a value of false because getting the CPU time for a thread other than the current thread is not supported.

SIGSEGV when creating a JVM using JNI (Linux only)

A call to JNI_CreateJavaVM() from a JNI application might cause a segmentation fault (signal SIGSEGV); to avoid this fault, rebuild your JNI program specifying the option –lpthread.

Lack of resources with highly threaded applications (Linux only)

If you are running with many concurrent threads, you might get a warning message:

java.lang.OutOfMemoryError

The message is an indication that your machine is running out of system resources and messages can be caused by the following reasons:

If your Linux® installation uses LinuxThreads, rather than NPTL, the number of processes created exceeds your user limit.
Not enough system resources are available to create new threads. In this case, you might also see other exceptions, depending on what your application is running.
Kernel memory is either running out or is fragmented. You can see corresponding Out of Memory kernel messages in /var/log/messages. The messages are associated with the ID of the killed process.

Try tuning your system to increase the corresponding system resources.

AESNI support on x86 platforms (Linux and Windows only)

Software exploitation of AESNI instructions on x86 architectures is currently not supported with the balanced or metronome GC policies.

Language Environment® runtime options that cause ABENDs (z/OS only)

If the Language Environment runtime option TERMTHDACT is set to UAIMM, unexpected 0C7 ABENDs might be reported. Although the ABENDs are reported, the Java™ virtual machine continues to run successfully. However, if the Language Environment run time option ERRCOUNT is set to a value that is greater than zero, the Java virtual machine might end when the value that you specified for ERRCOUNT is reached. This behavior occurs on 31-bit and 64-bit environments. To avoid this problem, run the Java virtual machine with the -Xrs:sync option. This option suppresses the use of compare-and-trap and load-and-trap instructions by the JIT compiler, while allowing the Java virtual machine to handle synchronous signals. So, for example, you can still use the SIGQUIT signal to collect a javacore dump, or the SIGTERM signal to shut down the Java virtual machine. For more information about this option, see -Xrs in the OpenJ9 user documentation.

To override the system-wide TERMTHDACT setting, you can pass a Language Environment parameter that excludes the UAIMM option in your batch job. For example:

// LEPARM='TERMTHDACT(TRACE,CESE,00000096),ERRCOUNT(0)'

Note: Do not set the TRAP(OFF) option to prevent the notification of abends, because this setting disables POSIX signal handling, on which the Java virtual machine depends. If the TRAP(OFF) option is required, for example when you mix Java programs with native z/OS programs, run the Java virtual machine with the -Xrs option, which suppresses all uses of signals by the Java virtual machine. For more information about the TRAP option, see the documentation for your version of z/OS, for example: TRAP.

Threads as processes (Linux only)

On Linux systems, the VM implements Java threads as native threads. On NPTL-enabled systems such as RHEL and SLES, these are implemented as threads. However using the LinuxThreads library results in each thread being a separate Linux process.

If the number of Java threads exceeds the maximum number of processes allowed, your program might:

Get an error message
Get a SIGSEGV error
Stop

The native stack size is the main limitation when running many threads. Use the -Xss option to reduce the size of the thread stack so that the JVM can handle the required number of threads. For example, set the stack size to 32 KB on startup.

Floating stack limitations

If you are running without floating stacks, regardless of what is set for -Xss, a minimum native stack size of 256 KB for each thread is provided.

On a floating stack Linux system, the -Xss values are used. If you are migrating from a non-floating stack Linux system, ensure that any -Xss values are large enough and are not relying on a minimum of 256 KB.

glibc limitations

If you receive a message indicating that the libjava.so library could not be loaded because of a symbol not found (such as __bzero), you might have an earlier version of the GNU C Runtime Library, glibc, installed. The SDK for Linux thread implementation requires glibc version 2.3.2 or greater.

Using -Xshareclasses:destroy during JVM startup

When running the command java -Xshareclasses:destroy on a shared cache that is being used by a second JVM during startup, you might have the following issues:

The second JVM fails.
The shared cache is deleted.

Large page request fails

There is no error message issued when the JVM is unable to honor the -Xlp request.

There are a number of reasons why the JVM cannot honor a large page request. For example, there might be insufficient large pages available on the system at the time of the request. To check whether the -Xlp request was honored, you can review the output from -verbose:gc. Look for the attributes requestedPageSize and pageSize in the -verbose:gc log file. The attribute requestedPageSize contains the value specified by -Xlp. The attribute pageSize is the actual page size used by the JVM.

ThreadMXBean thread CPU time might not be monotonic on SMP systems

On SMP systems, the times returned by ThreadMXBean.getThreadUserTime(), ThreadMXBean.getThreadCpuTime(), ThreadMXBean.getCurrentThreadUserTime(), and ThreadMXBean.getCurrentThreadCpuTime() might not increase monotonically if the relevant thread migrates to a different processor.