the OutOfMemoryError zoo

the picture

you know how an OutOfMemoryError in a log makes everyone reach for -Xmx? that's like hearing "we ran out" in a kitchen and ordering more flour, when it was the gas that ran out. a JVM has several separate pools, each with its own limit, and each one throws its own flavour of the same error.

the zoo

every one of these was reproduced on jdk 25 with a tiny program and a tiny limit (-Xmx16m, -XX:MaxMetaspaceSize=16m and so on), so they die in milliseconds instead of hours. the messages are copied from the real output.

a few patterns in there are worth saying out loud:

• two of them aren't about memory. Requested array size exceeds VM limit and Required array length ... is too large are about a length past Integer.MAX_VALUE - 2. you'd get them with a terabyte of free heap.
• unable to create native thread is about threads. this one says "possibly out of memory" in its own message, and it's usually a thread limit: 6,124 threads in on macOS (which caps a process at 6,144), a ulimit -u or a container's pid limit on linux.
• the collector changes the message. the exact same program said GC overhead limit exceeded under Parallel and Java heap space under G1. only Parallel implements the overhead limit.

what the JVM tries first

a heap OutOfMemoryError is never the first thing that happens. by the time you see one, the collector has already tried everything it's allowed to:

that's also why a JVM near the edge feels so slow before it dies: it's running full GCs back to back, each one freeing a little less (what that looks like in a log is in reading GC logs). the error is the end of a long, expensive goodbye.

a thread dies, not the JVM

import java.util.*;
 
public class Worker {
    public static void main(String[] args) throws Exception {
        Thread worker = new Thread(() -> {
            List<byte[]> keep = new ArrayList<>();
            while (true) keep.add(new byte[1024 * 1024]);
        }, "worker");
        worker.start();
        worker.join();
        System.out.println("main is still alive, worker is " + worker.getState());
    }
}

which is why production services usually want the JVM to give up on the first one:

$ java -Xmx16m -XX:+ExitOnOutOfMemoryError Heap.java
Terminating due to java.lang.OutOfMemoryError: Java heap space
$ echo $?
3

HeapDumpOnOutOfMemoryError plus ExitOnOutOfMemoryError is a sane default: you get the dump for later and a fresh process now. but as the zoo shows, neither fires for direct buffer memory, for thread creation, or for the length limits thrown by library code. those still need to be caught by your logs.

the one that doesn't throw

the scariest out-of-memory has no message at all. a container has a memory limit for the whole process: heap, metaspace, thread stacks, direct buffers, everything in native memory. go over it and the kernel's OOM killer sends SIGKILL. the JVM gets no chance to throw, log, dump or run a hook. all you see is the process gone and an exit code of 137 (128 + signal 9). if your service restarts with 137 and your logs are clean, look at the process's total memory, not at the heap.