Understanding memory usage

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-bit 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 32-bit AIX Virtual Memory Model
AIX assigns a virtual address space partitioned into 16 segments of 256 MB.
The 64-bit AIX Virtual Memory Model
The 64-bit model allows many more segments, although each segment is still 256 MB.
Changing the Memory Model (32-bit JVM)
Three memory models are available on the 32-bit JVM.
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.
The AIX 32-bit JVM default memory models
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 in AIX, for use with the IBM® JVM. For most applications the performance gains that result from using the variable are likely to be small. It particularly benefits any application that makes heavy use of malloc calls in the 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.
Receiving OutOfMemoryError exceptions
An OutOfMemoryError exception results from running out of space on the Java heap or the native heap.
Is the Java or native heap exhausted?
Some OutOfMemory conditions also carry an explanatory message, including an error code.
Java heap exhaustion
The Java heap becomes exhausted when garbage collection cannot free enough objects to make a new object allocation.
Native heap exhaustion
You can identify native heap exhaustion by monitoring the svmon snapshot output
AIX fragmentation problems
Tracing leaks
Some useful techniques for tracing leaks are built into the JVM.
Using Heapdump to debug memory leaks
You can use Heapdump to analyze the Java Heap.
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.

Parent topic: AIX problem determination