Oc4j Gives Java.Lang.Outofmemoryerror Even When Heap Is Not Full (Doc ID 803858.1)

Last updated on FEBRUARY 13, 2024

Applies to:

Symptoms

The error "JAVA.LANG.OUTOFMEMORYERROR" is being reported in the oc4j container log. This may happen regularly or infrequently.

The total RAM available to the machine, as reported by 'top' is very low. So typically on a 2-gig machine only 100-meg is showing as available.

The opmn.xml file shows that the oc4j containers have been configured with a smaller Xms value than Xmx. This means the heap will naturally grow / contract according to load.

Either by adding verbose:gc to the java options or by monitoring with Sun's visualGC tool, it is noticed that at the time of the error, the java heap is not full.

Running 'top' shows the java process RSS column (approximately equivalent to RAM in use) growing steadily, reflecting the fact that the heap size is growing (this being expected behaviour.)

Another clue you may see is the type of OutOfMemory shown:

"Exception in thread "main" java.lang.OutOfMemoryError: request bytes for . Out of swap space?"
or
"Exception in thread "main" java.lang.OutOfMemoryError: " followed by "(Native method)"

can both signify either a memory  leak of some sort, or the fact that available operating system memory has run out.

Changes

There is insufficient RAM on the machine.

If you get OutOfMemory on a java process and diagnostics such as verbose:gc and visualGC do not show the heap as being full, the likelihood is that the machine has run out of memory.

When Xms is less than Xmx, the heap starts smaller and an increasing RSS size in top is likely to indicate normal growth of heap.

Cause

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.