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.
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.
org.gradle.jvmargs=-Xmx4g -XX:MaxMetaspaceSize=1gMatch 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.
./gradlew build --no-daemon -Dorg.gradle.jvmargs=-Xmx3gHow to prevent it
- Set
org.gradle.jvmargsheap 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.