When we encounter a java.lang.OutOfMemoryError, we often find that Java heap dumps, along with other artifacts, are generated by the Java Virtual Machine. If you feel like jumping right into a Java heap dump when you get a java.lang.OutOfMemoryError, don't worry, it's a normal thought. You may be able to discover something serendipitously, but it's not always the best idea to analyze Java heap dumps, depending on the situation you are facing. We first need to investigate the root cause of the java.lang.OutOfMemoryError.

Only after the root cause is identified can we decide whether or not to analyze Java heap dumps. What is a java.lang.OutOfMemoryError? Why in the world does it occur? Let's find out.

What Is a java.lang.OutOfMemoryError?
A java.lang.OutOfMemoryError is a subclass of java.lang.VirtualMachineError that is thrown when the Java Virtual Machine is broken or has run out of resources that are necessary to continue the operation of the Java Virtual Machine. Obviously, memory is the exhausted resource for a java.lang.OutOfMemoryError, which is thrown when the Java Virtual Machine cannot allocate an object due to memory constraints. Unfortunately, the Java specification of java.lang.OutOfMemoryError does not elaborate further on what kind of memory it's talking about.

There are six different types of runtime data areas, or memory areas, in the Java Virtual Machine (see Figure 1).

1. Program Counter Register
2. Java Virtual Machine Stack
3. Heap
4. Method Area
5. Runtime Constant Pool
6. Native Method Stack

The Program Counter Register, also known as the pc register, stores the address of the Java byte code instruction that is currently being executed (just like the processor register in your central processing unit of the device from which you are reading or printing this article). You will not see a java.lang.OutOfMemoryError from the pc register since a program counter is not conventionally considered as a memory.

Java Virtual Machine Stacks contain frames where data, return values, and partial execution results are stored. Java Virtual Machine Stacks can be expanded during runtime. If there's not enough memory for the expansion of an existing Java Virtual Machine stack, or for the creation of a new Java Virtual Machine stack for a new thread, the Java Virtual Machine will throw a java.lang.OutOfMemoryError.

The Heap is where instances of Java classes and arrays are allocated. A java.lang.OutOfMemoryError will be thrown when there is not enough memory available for instances of Java classes or arrays.

The Method Area stores class-related information, the runtime constant pool, for instances, the code for methods and constructors, and field/method data. If there's not enough memory in the method area, you will encounter java.lang.OutOfMemoryError.

The Runtime Constant Pool contains constants such as field references and literals. A java.lang.OutOfMemoryError will be thrown when not enough memory is available for the construction of the runtime constant pool area.

Native Memory Stacks store conventional stacks, also known as C stacks, to support native methods that are written in a non-Java language such as C/C++. Native memory stacks can be expanded during runtime. If there's not enough memory for the expansion of an existing native memory stack or for the creation of a new native memory stack for a new thread, you would see a java.lang.OutOfMemoryError.

You may have seen a java.lang.StackOverflowError, which is completely different from a java.lang.OutOfMemoryError. A java.lang.StackOverflowError is thrown when native memory stacks or Java Virtual Machine stacks need more memory than is configured. In most IBM Java Virtual Machine implementations, the -Xmso command-line option controls the stack size for operation system threads or native thread, and the -Xss command-line option controls the stack size for Java threads. In some implementations, such as Sun Microsystems HotSpot Java Virtual Machine, the Java methods share stack frames with C/C++ native code. The maximum stack size for a thread can be configured with the -Xss Java command-line option. The default sizes of these options vary by platform and implementation, but are usually between 256 Kbytes-1024 Kbytes. Please refer to the documentation of your Java virtual machine for more specific information. We will cover more about java.lang.StackOverflowError in a separate article.

Now that we understand which memory areas could cause a java.lang.OutOfMemoryError, let's take a look at actual error messages. What does a java.lang.OutOfMemoryError look like and how can I address each symptom? Have you ever seen a java.lang.OutOfMemoryError similar to the following?

java.lang.OutOfMemoryError: Requested array size exceeds VM limit

This error message indicates that there is a memory request for an array but that's too large for a predefined limit of a virtual machine. What do we do if we encounter this kind of java.lang.OutOfMemoryError? We need to check the source code to make sure that there's no huge array created dynamically or statically. Fortunately, latest virtual machines usually do not have this limit.

java.lang.OutOfMemoryError: PermGen space

You will see an OutOfMemoryError when the Permanent Generation area of the Java heap is full, like the above message.

On some Java Virtual Machines, such as Sun Microsystems' HotSpot Java Virtual Machine, a dedicated memory area called permanent generation (or permanent region) stores objects that describe classes and methods. We can visualize the usage of a permanent generation with the IBM Pattern Modeling and Analysis Tool for the Java Garbage Collector.

In Figure 2 we enabled the "Max Perm" button and  the "Used Tenured" button to visualize permanent generation usage and its maximum size. We can see that the used amount of permanent generation reaches its maximum limit. That's why we're getting the java.lang.OutOfMemoryError: PermGen space message. If there's no memory leak, we can just use the -XX:MaxPermSize command-line option to increase the maximum limit of the permanent generation. For example,

-XX:MaxPermSize=128m

will set the maximum size of the permanent generation to 128 Mbytes.

So far we've seen a Java.lang.OutOfMemoryError due to exhaustion in the Java heap or an area in the Java heap such as permanent generation. Surprisingly, a Java.lang.OutOfMemoryError can be thrown when the Java Virtual Machine cannot find any more memory in the native memory as well as in the Java heap. How can we tell whether it's caused by the Java heap or native memory?

In the following message, there's no information in the message whether java.lang.OutOfMemoryError is caused by the Java heap or native memory:

JVMDUMP013I Processed dump event "systhrow", detail "java/lang/OutOfMemoryError".

In the following case, the Java virtual machine is kind enough to tell us that there's native memory exhaustion. In the message, the Java virtual machine says "allocateMemory failed" which means a native memory allocation failed:

java.lang.OutOfMemoryError: JVMCI046: allocateMemory failed

In the following message, there's no clue as to whether it's native memory or a Java heap. Fortunately we have a line number, 20, and the source code file name, HeapExhaustionSimulator.java. This might be Java heap related.

JVMDG274: Dump Handler has Processed OutOfMemory.
Exception in thread "main" java.lang.OutOfMemoryError
at HeapExhaustionSimulator.main(HeapExhaustionSimulator.java:20)

In the following message, there's no clue whether it's native memory or a Java heap. But "sun.misc.Unsafe.allocateMemory(Native Method)" indicates that it might be native memory related.

Exception in thread "main" java.lang.OutOfMemoryError
at sun.misc.Unsafe.allocateMemory(Native Method)
at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:99)
at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:288)
at NativeMemorySimulator.main(NativeMemorySimulator.java:11)

In the following message, the  Java Virtual Machine indicates that the Java heap space is related to the java.lang.OutOfMemoryError.

java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid6280.hprof ...
Heap dump file created [50549348 bytes in 1.444 secs]

You may have seen a java.lang.OutOfMemoryError similar to the following:

java.lang.OutOfMemoryError: requested NNN bytes for MMMM. Out of swap space?

Literally you could check the operating system configuration for swap space. It seems that the Java Virtual Machine is not sure if the swap space is the root cause of the problem (?).We can check whether this Java Virtual Machine is consuming too much native memory .We also need to make sure there's enough memory for this JVM and no other processes are consuming most of memory resource. The last thing we can try is to find any known defects related to the module, MMMM.

java.lang.OutOfMemoryError: unable to create new native thread

This kind of message is seen when you have an excessive number of threads or if the native memory is exhausted and a thread is attempting to be created.

What Is a Java Heap Dump?
We've learned that a Java heap is a runtime data area where all class instances and arrays are allocated and shared among all Java Virtual Machine threads during execution of the JVM. A Java heap dump is a snapshot of a Java heap at a specific time. It's like taking a picture of a busy warehouse at a given time. If we look at the picture, we can identify what items were available at that time. Some items may be shipped to Canada a few minutes later, but you can see them in the picture because they were there at the time of the snapshot.

Because the Java specification does not mention the Java heap dump, there are different forms of Java heap dump implementations from different Java Virtual Machines. The IBM Java heap dump provides information mostly about the Java heap.

The Sun Microsystems hprof Java heap dump provides information about the Java Virtual Machine stacks, the runtime constant pool as well as the Java heap.

How Can I Generate Java Heap Dumps?
A Java heap dump is usually automatically generated by the Java Virtual Machine, but you can also force Java heap dump generation. On most IBM Java Virtual Machines, Java heap dumps are generated automatically when the Java heap becomes exhausted. On most Sun Microsystems JVMs, you need to configure the virtual machine to generate Java heap dumps. If you want to generate a Java heap dump when a java.lang.OutOfMemoryError occurs, you need to set the -XX:+HeapDumpOnOutOfMemoryError command-line option on certain releases of Sun's JVM. You could also use a HPROF profiler by using the -agentlib:hprof=heap=dump command-line option. You could also use jmap if your Sun JVM provides the utility. For example, jmap -dump 1234 will generate the Java heap dump from the process whose identifier is 1234. You could utilize JConsole by calling the HotSpotDiagnostic MBean and the dumpHeap operation if it's available from your Sun JVM.

If you want to generate Java heap dumps for Java virtual machine crashes (an unexpected termination of process) or user signals on IBM JVMs, you can set the environment variable IBM_HEAPDUMP or IBM_HEAP_DUMP to TRUE. For example, you can send the IBM Java virtual machine the signal SIGQUIT for the Linux operating systems and AIX operating systems or SIGINT(Control-Break key combination) for Windows to generate Java heap dumps. The IBM JVM provides an API, com.ibm.jvm.Dump.HeapDump(), that you can invoke from application code to generate Java heap dumps programmatically.

Please refer to the documentation of your JVM for detailed information since these options vary by platform and implementation.

Where Can I Find Java Heap Dumps?
You can find Java heap dumps in the current working directory of the Java Virtual Machine process, unless you specify a different location. You can specify the location with the environment variable IBM_HEAPDUMPDIR or _CEE_DMPTARG on IBM JVMs. If there's not enough space available for Java heap dumps or the JVM cannot acquire write-permission in the location, Java heap dumps are generated to the operating system's temporary directory on the IBM JVM. Please refer to your operating system manual for the location of the system's temporary directory and its configuration.

What Do Java Heap Dumps Look Like and How Can I read Them?
Nowadays, the majority of Java heap dump formats are generated in binary. Thus you might want to use a tool unless your brain can interpret hexadecimal codes without any headaches.

The IBM HeapAnalyzer is one of the most popular Java heap analysis tools. It can analyze all Java heap dump formats provided by Sun, HP and most of the Java heap dump formats provided by IBM. It's powered by object query engines and patent-pending heuristic analysis engines. I've been developing the IBM HeapAnalyzer from scratch since 2003, spending my vacation, weekends and weeknights on it. The IBM HeapAnalyzer was so successful that IBM decided to make the IBM HeapAnalyzer an official IBM software product and bundle it with existing products. So I donated all the source code of IBM HeapAnalyzer to IBM to run it on an Eclipse-based interface. Now the IBM HeapAnalyzer has a daughter, MDD4J, which always reminds me of my late daughter lost while I was working on the MDD4J project. The IBM HeapAnalyzer has been the top technology at IBM alphaWorks for six consecutive years since its inception as of March 2009.

Whether your Java heap dump is in binary or text/ascii format, the heap dump contains information about all the live objects that are on the Java heap such as address, object size, and referenced addresses. Let's take a look at the text/ascii format Java heap dumps since binary heap dumps have similar information but are in hexadecimal format to save disk space.

'); for(i = 0; i < google_ads.length; ++i) { document.write('
• '); document.write('' + google_ads[i].line1 + '
  '); document.write('' + google_ads[i].visible_url + '
  '); document.write(google_ads[i].line2 + ' ' + google_ads[i].line3); document.write('
'); } document.write('