Archive for September 2010

The Java Virtual Machine (JVM)* has the following types of memory: heap, non-heap, and native.

Heap memory is the runtime data area from which memory for all class instances and arrays is allocated. Non-heap memory includes the method area and memory required for the internal processing or optimization of the JVM. It stores per-class structures such as a runtime constant pool, field and method data, and the code for methods and constructors. Native memory is the virtual memory managed by the operating system. When the memory is insufficient for an application to allocate, a java.lang.OutOfMemoryError will be thrown.

Following are the possible error messages for OutOfMemoryErrors in each type of memory:

Heap memory error: When an application creates a new object but the heap does not have sufficient space and cannot be expanded further, an OutOfMemoryError will be thrown with the following error message:

java.lang.OutOfMemoryError: Java heap space

Non-heap memory error: The permanent generation is a non-heap memory area in the HotSpot VM implementation that stores per-class structures as well as interned strings. When the permanent generation is full, the application will fail to load a class or to allocate an interned string, and an OutOfMemoryError will be thrown with the following error message:

java.lang.OutOfMemoryError: PermGen space

Native memory error: The Java Native Interface (JNI) code or the native library of an application and the JVM implementation allocate memory from the native heap. An OutOfMemoryError will be thrown when an allocation in the native heap fails. For example, the following error message indicates insufficient swap space, which could be caused by a configuration issue in the operating system or by another process in the system that is consuming much of the memory:

java.lang.OutOfMemoryError: request bytes for .
Out of swap space?

An insufficient memory problem could be due either to a problem with the configuration — the application really needs that much memory — or to a performance problem in the application that requires you to profile and optimize to reduce the memory use.

You can find more information at

PermGen holds the metadata about classes that have been loaded/created. This information is garbage collected like the other parts of the heap, however there are rough edges that can prevent this from happening, class loaders in particular. Generally, the amount of PermGen space needed is small in relation to the rest of the heap.

How do I know what classes are being loaded or unloaded? Use the command line options

-XX:+TraceClassLoading and -XX:+TraceClassUnloading .

If you suspect that that classloader isn’t the issue, use -verbose:class to investigate classes which have been loaded. This, as it suggests, will be very verbose.

How do you increase PermGen space?

Increase using the -XX:MaxPermSize option.