Gradle Daemon OutOfMemoryError - Fix org.gradle.jvmargs in CI

By Daniel Zoghalchali·Latchkey

The Gradle daemon JVM threw an OutOfMemoryError - it ran out of Java heap or Metaspace while configuring or building. Unlike a killed daemon, here the JVM itself reports the failure.

What this error means

The build fails with java.lang.OutOfMemoryError: Java heap space (or Metaspace) attributed to the Gradle daemon, often during configuration of a large multi-module build or while running many annotation processors.

gradle output

FAILURE: Build failed with an exception.
* What went wrong:
java.lang.OutOfMemoryError: Java heap space
# or
java.lang.OutOfMemoryError: Metaspace

Common causes

Daemon heap too small for the build graph

Large multi-module configurations, big dependency graphs, or heavy plugins need more heap than the default. The daemon exhausts -Xmx and throws.

Metaspace exhausted by class loading

Many plugins, annotation processors, and configuration-cache class loading can fill Metaspace, especially across a reused daemon, producing OutOfMemoryError: Metaspace.

How to fix it

Raise heap and Metaspace for the daemon

Set both in gradle.properties so every invocation uses them.

gradle.properties

# gradle.properties
org.gradle.jvmargs=-Xmx3g -XX:MaxMetaspaceSize=1g -XX:+HeapDumpOnOutOfMemoryError

Reduce peak memory

Lower parallelism with org.gradle.workers.max so fewer JVMs run at once.
Limit forked test JVM memory via the test { maxHeapSize = "1g" } block.
Use --no-daemon in CI so Metaspace does not accumulate across builds.

How to prevent it

Set org.gradle.jvmargs heap and Metaspace relative to the runner RAM.
Bound forked worker count and test-JVM heap.
Prefer --no-daemon in ephemeral CI to avoid Metaspace creep.

Frequently asked questions

What causes "Daemon "OutOfMemoryError""?

Large multi-module configurations, big dependency graphs, or heavy plugins need more heap than the default. The daemon exhausts -Xmx and throws.

How do I fix Daemon "OutOfMemoryError"?

Set both in gradle.properties so every invocation uses them.

Can Latchkey fix this automatically?

Yes. Latchkey runs your GitHub Actions on managed runners that detect this failure, apply the fix, and retry the job automatically - self-healing is on by default.