Introduction

The Gradle build daemon runs as a separate JVM process. For large projects, especially Android builds with many modules, the daemon can exceed available memory and be killed by the operating system's OOM killer. Unlike a Java OutOfMemoryError, an OOM kill produces no stack trace: the process simply disappears, and Gradle reports a cryptic "build daemon disappeared" error.

Symptoms

  • Gradle build daemon disappeared unexpectedly
  • Build daemon has been stopped with exit code 137 (SIGKILL)
  • Build fails at different points each time (non-deterministic)
  • Works on machine with 16GB RAM but fails on 8GB machine
  • dmesg shows Out of memory: Killed process (gradle)
  • Android Studio build hangs then fails with no useful error

Example error: ``` FAILURE: Build failed with an exception.

* What went wrong: Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)

* Try: Run with --info or --debug option to get more log output. Run with --scan to get full insights. ```

Check dmesg for confirmation: ``bash $ dmesg | grep -i oom [12345.678] Out of memory: Killed process 12345 (java) total-vm:8234567kB, anon-rss:4123456kB

Common Causes

  • Insufficient heap size configured in gradle.properties
  • Too many parallel builds consuming memory simultaneously
  • Large number of Kotlin compilation units with full module graphs
  • CI/CD runner has limited memory (e.g., GitHub Actions 2-core 7GB)
  • Memory leak in a Gradle plugin

Step-by-Step Fix

  1. 1.Increase Gradle daemon heap size:
  2. 2.```properties
  3. 3.# gradle.properties
  4. 4.org.gradle.jvmargs=-Xmx4g -XX:MaxMetaspaceSize=1g -XX:+HeapDumpOnOutOfMemoryError
  5. 5.org.gradle.daemon=true
  6. 6.`
  7. 7.Enable parallel builds and configure workers:
  8. 8.```properties
  9. 9.# gradle.properties
  10. 10.org.gradle.parallel=true
  11. 11.org.gradle.caching=true
  12. 12.org.gradle.configureondemand=true

# Limit the number of parallel workers org.gradle.workers.max=4 ```

  1. 1.Optimize for CI environments with limited memory:
  2. 2.```properties
  3. 3.# gradle.properties (CI-specific)
  4. 4.org.gradle.jvmargs=-Xmx2g -XX:MaxMetaspaceSize=512m
  5. 5.org.gradle.parallel=false
  6. 6.org.gradle.daemon=false

# In GitHub Actions: # - name: Build # run: ./gradlew build --no-daemon -Dorg.gradle.jvmargs="-Xmx2g" ```

  1. 1.Profile memory usage to find the culprit:
  2. 2.```bash
  3. 3.# Enable GC logging
  4. 4.org.gradle.jvmargs=-Xmx4g -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps

# Analyze heap dump (generated on OOM) jhat gradle_pid.hprof # Or use VisualVM / Eclipse MAT

# Run with memory profiling ./gradlew build --profile # Opens build/profile/ report in browser ```

  1. 1.Reduce Kotlin compiler memory usage:
  2. 2.```kotlin
  3. 3.// build.gradle.kts
  4. 4.tasks.withType<KotlinCompile> {
  5. 5.kotlinOptions {
  6. 6.jvmTarget = "17"
  7. 7.// Reduce memory by limiting incremental compilation scope
  8. 8.freeCompilerArgs = listOf(
  9. 9."-Xskip-metadata-version-check",
  10. 10."-Xinline-classes"
  11. 11.)
  12. 12.}
  13. 13.}

// Use K2 compiler (Kotlin 1.9+) which has better memory management kotlin { compilerOptions { useK2.set(true) } } ```

Prevention

  • Set org.gradle.jvmargs=-Xmx4g as a minimum for Android projects
  • Use GitHub Actions runners with more memory (ubuntu-latest with 7GB minimum)
  • Enable Gradle build cache to avoid recompilation
  • Run ./gradlew --status to check daemon health
  • Add CI memory monitoring and alerting
  • Consider Gradle Enterprise (Develocity) for build scan analysis
  • Pin Gradle and Kotlin plugin versions to avoid memory regressions