Before you can properly diagnose memory problems on AIX®, first you
must have an understanding of the AIX virtual memory model and how the JVM
interacts with it.
32- and 64-bit JVMs
Most of the information in this section about altering the memory
model and running out of native heap is relevant only to the 32-bit model,
because the 64-bit model does not suffer from the same kind of memory constraints.
The native and Java heaps
The JVM maintains two memory areas, the Java™ heap,
and the native (or system) heap. These two heaps have different purposes
and are maintained by different mechanisms.
Monitoring the native heap
You can monitor the memory usage of a process by taking a series
of snapshots over regular time intervals of the memory currently allocated
and committed.
Native heap usage
The native heap usage will normally grow to a stable level, and
then stay at around that level. You can monitor the amount of memory committed
to the native heap by observing the number of 'Inuse' pages in the svmon output.
Specifying MALLOCTYPE
You can set the MALLOCTYPE=watson environment variable,
available in AIX 5.3,
for use with the IBM® 5.0 JVM, but for most applications the performance
gains are likely to be small. It particularly benefits any application that
makes heavy use of malloc calls in native code.
Monitoring the Java heap
The most straightforward, and often most useful, way of
monitoring the Java heap is
by seeing what garbage collection is doing.
Submitting a bug report
If the data is indicating a memory leak in native JVM code,
contact the IBM service team. If the problem is Java heap exhaustion, it is much less likely
to be an SDK issue, although it is still possible.