Oc4j Gives Java.Lang.Outofmemoryerror Even When Heap Is Not Full
(Doc ID 803858.1)
Last updated on OCTOBER 12, 2020
Applies to:Oracle Containers for J2EE - Version 10.1.3.3.0 and later
Information in this document applies to any platform.
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?"
"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.
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.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document