Skip to content
Latchkey

Gradle "Expiring Daemon because JVM heap space is exhausted" in CI

The Gradle daemon noticed its JVM heap was nearly exhausted and expired itself to avoid thrashing. On the next build the daemon is recreated, but the in-flight build can fail with a daemon-disappeared error when the heap is too small for the work.

What this error means

The log prints "Expiring Daemon because JVM heap space is exhausted" and the build may then fail with "Gradle build daemon disappeared unexpectedly" or an OutOfMemoryError.

Gradle
Expiring Daemon because JVM heap space is exhausted
> Gradle build daemon disappeared unexpectedly
  (it may have been killed or may have crashed)

Common causes

The daemon heap is too small for the build

A large multi-module build or annotation processing needs more heap than the default -Xmx, so the daemon runs out and expires.

A constrained CI runner with limited memory

On a small runner, the heap plus other processes exceed available memory, pushing the daemon into expiry.

How to fix it

Raise the daemon heap

Give the daemon more heap via org.gradle.jvmargs so it does not exhaust during the build.

gradle.properties
org.gradle.jvmargs=-Xmx4g -XX:MaxMetaspaceSize=1g

Match the heap to the runner size

Set the heap below the runner memory ceiling, and disable the daemon for short single-shot CI jobs if memory is very tight.

Terminal
./gradlew build --no-daemon -Dorg.gradle.jvmargs=-Xmx3g

How to prevent it

  • Set org.gradle.jvmargs heap explicitly for CI rather than relying on defaults.
  • Keep the heap below the runner memory limit to avoid OOM kills.
  • Profile heavy modules so memory growth is bounded.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →