On why and how to exit JVM on OnOutOfMemoryError

October 15, 2017
JVM OpenJDK

For a long time all my JVM-based Docker images were configured to exit on OOM error with -XX:OnOutOfMemoryError=”kill -9 %p” (%p is the current JVM process PID placeholder). It works well with XX:+HeapDumpOnOutOfMemoryError, because JVM will dump heap first, and then execute OnOutOfMemoryError command (see the relevant code in vm/utilities/debug.cpp). But with version 8u92 there’s now a JVM option in the JDK to make the JVM exit when an OutOfMemoryError occurs:

ExitOnOutOfMemoryError

When you enable this option, the JVM exits on the first occurrence of an out-of-memory error. It can be used if you prefer restarting an instance of the JVM rather than handling out of memory errors.

CrashOnOutOfMemoryError

If this option is enabled, when an out-of-memory error occurs, the JVM crashes and produces text and binary crash files. Enhancement Request: JDK-8138745 (parameter naming is wrong though JDK-8154713, ExitOnOutOfMemoryErroR instead of ExitOnOutOfMemory)

Why exit on OOM? OutOfMemoryError may seem like any other exception, but if it escapes from Thread.run() it will cause thread to die. When thread dies it is no longer a GC root, and thus all references kept only by this thread are eligible for garbage collection. While it means that JVM has a chance recover from OOME, its not recommended that you try. It may work, but it is generally a bad idea. See this answer on SO.

JVM in Docker and PTRACE_ATTACH

December 19, 2016
Docker Linux ptrace JVM

Single-file Play Framework application with Ammonite

September 18, 2016
Scala PlayFramework JVM

Kto wywołuje System.gc() ?

July 25, 2013
JVM BTrace