Download Diagnostics Guide IBM Developer Kit and Runtime Environment, Java

You can also analyze z/OS console (SVC) dumps using the system dump viewer
provided in the SDK, see Chapter 24, “Using system dumps and the dump
viewer,” on page 263.
The process is performing badly
If you have no evidence of a deadlock or an infinite loop, the process is probably
suffering from very bad performance. Bad performance can be caused because
threads have been placed into explicit sleep calls, or by excessive lock contention,
long garbage collection cycles, or for several other reasons. This condition is not a
hang and should be handled as a performance problem.
See “Debugging performance problems” on page 163 for more information.
Understanding Memory Usage
To debug memory leaks you need to understand the mechanisms that can cause
memory problems, how the JVM uses the LE HEAP, how the JVM uses z/OS
virtual storage, and the possible causes of a java.lang.OutOfMemoryError
exception.
Memory problems can occur in the Java process through two mechanisms:
v A native (C/C++) memory leak that causes increased usage of the LE HEAP,
which can be seen as excessive usage of Subpool2, Key 8, or storage, and an
excessive Working Set Size of the process address space
v A Java object leak in the Java-managed heap. The leak is caused by
programming errors in the application or the middleware. These object leaks
cause an increase in the amount of live data that remains after a garbage
collection cycle has been completed.
Allocations to LE HEAP
The Java process makes two distinct allocation types to the LE HEAP.
The first type is the allocation of the Java heap that garbage collection manages.
The Java heap is allocated during JVM startup as a contiguous area of memory. Its
size is that of the maximum Java heap size parameter. Even if the minimum,
initial, heap size is much smaller, you must allocate for the maximum heap size to
ensure that one contiguous area will be available should heap expansion occur.
The second type of allocation to the LE HEAP is that of calls to malloc() by the
JVM, or by any native JNI code that is running under that Java process. This
includes application JNI code, and vendor-supplied native libraries; for example,
JDBC drivers.
z/OS virtual storage
To debug these problems, you must understand how C/C++ programs, such as the
JVM, use virtual storage on z/OS. To do this, you need some background
understanding of the z/OS Virtual Storage Management component and LE.
The process address space on 31-bit z/OS has 31-bit addressing that allows the
addressing of 2 GB of virtual storage. The process address space on 64-bit z/OS
has 64-bit addressing that allows the addressing of over 2 GB of virtual storage.
This storage includes areas that are defined as common (addressable by code
running in all address spaces) and other areas that are private (addressable by
code running in that address space only).
Chapter 13. z/OS problem determination
161