skip to content

How does the daemon's heap and metaspace sizing affect build throughput, and what symptom tells you the JVM is the bottleneck?

level: middleimportance: must knowfreq 48%

answer

  1. daemon = one heap for whole build
  2. small heap → frequent / full GC → pauses
  3. GC time stolen from build throughput
  4. metaspace = class metadata, separate budget
  5. symptom: slow despite warm+cache, then OOM

basics

~20 s

If the daemon heap is too small, the JVM spends excessive time in garbage collection, stealing CPU from the build and slowing it down. Adequate heap and metaspace let work proceed with minimal GC pauses.

solid answer

~50 s

The daemon does all build work inside one JVM, so its heap and metaspace bound how much it can hold before the garbage collector runs. An **undersized heap** forces frequent collections and, worse, long full/old-generation GCs that **pause the build** and burn CPU that should be doing work — throughput drops sharply. **Metaspace** holds class metadata; large builds with many plugins/classes can exhaust it and trigger costly class-unloading GCs or OOM. The tell-tale symptom is a build that's slow despite a warm daemon and good caching, where GC logs show high GC time or repeated full collections, often ending in `OutOfMemoryError: Java heap space`. The fix is sizing the heap to the working set (so steady-state collections are short and infrequent) while not over-provisioning so far that the OS swaps. Sizing is configured via daemon JVM args, but the *performance* point is matching heap to the build's live-data footprint.

code

bash · 3 lines
bash
# Enable unified GC logging on the daemon to see if GC is the bottleneck
# (Java 9+). High % time in GC or repeated Full GCs => undersized heap.
-Xlog:gc*:file=daemon-gc.log:time,uptime,level,tags

go deeper

for a junior

Know that too little memory makes the JVM garbage-collect a lot, which slows the build.

for a middle

Explain heap vs. metaspace, that GC steals CPU/pauses threads, and the symptom: slow despite warm daemon + cache, sometimes OOM.

for a senior

Diagnose with GC logs, reason about live-set sizing, and warn about over-provisioning causing swap.

for a principal

Standardize daemon memory budgets across a multi-module monorepo and CI fleet, balancing per-runner RAM against GC pause SLAs.

## Why heap matters for a build tool The Gradle **daemon** runs the entire build — configuration, dependency graphs, task inputs/outputs snapshots, in-memory caches — inside **one JVM heap**. The heap is split into generations; short-lived objects die in the young generation (cheap minor GCs), survivors get promoted to the old generation. The JVM triggers garbage collection when a region fills. ### The throughput connection GC is **not free CPU**. With a heap too small for the build's **live set** (objects still reachable), the JVM collects constantly and may run **full GCs** that, depending on the collector, *stop the world* — every build thread pauses. Time spent in GC is time not spent building, so throughput falls. The classic failure mode is a build that hangs near the end and then throws: ``` FAILURE: ... java.lang.OutOfMemoryError: Java heap space ``` or the subtler version: it *finishes* but is slow because 20–40% of wall time is GC. ### Metaspace **Metaspace** (off-heap since Java 8) stores **class metadata** — and big multi-module builds with many plugins load enormous numbers of classes. Exhausting it causes `OutOfMemoryError: Metaspace` or aggressive class-unloading cycles. It's a separate budget from the heap. ## Diagnosing it Turn on GC logging for the daemon and look at GC time / pause counts. Signs the JVM is the bottleneck: - Slow build **despite** a warm daemon and cache hits. - Frequent or long full GCs in the log. - Intermittent OOM under the heaviest module. ## Sizing principle Size the heap to comfortably hold the **working set** so steady-state minor GCs are short and full GCs are rare — but don't over-allocate to the point the OS pages/swaps, which is far slower than GC. The sizing is *applied* through daemon JVM arguments; the **performance reasoning** — match heap and metaspace to the live-data footprint to minimize GC pause time — is the point here. ```bash # Add GC logging to the daemon to confirm GC is the bottleneck (Java 9+) # (set via the daemon's JVM args; observe %time in GC and pause lengths) -Xlog:gc*:file=daemon-gc.log:time,level,tags ```

  • How would you confirm the heap is the bottleneck rather than disk or network?
    Enable GC logging on the daemon and measure the share of wall time spent in GC and the frequency/length of full collections. High GC time with cache hits and a warm daemon points at the heap; I/O or resolution slowness would show elsewhere.
  • Why can over-sizing the heap also hurt?
    Allocating more than physical RAM (across daemon + compilers + OS) causes the OS to swap pages to disk; swapping is orders of magnitude slower than GC, so a too-large heap can be worse than a slightly small one.

saying these in an interview costs you the question

  • Treating metaspace and heap as the same pool — they are budgeted separately.
  • Assuming 'bigger heap is always faster' — over-provisioning can cause swapping and longer full-GC pauses.
  • Blaming slow builds on GC without ever enabling GC logging to confirm.

context

resolving links…