J9 issues and limitations
Known issues or limitations that you might encounter in specific system environments, or configurations.
- ThreadMXBean Thread User CPU Time limitation
-
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.
- Language Environment® runtime options that cause ABENDs
-
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. 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. - 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.
- 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
andpageSize
in the -verbose:gc log file. The attributerequestedPageSize
contains the value specified by -Xlp. The attributepageSize
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.