What does the JVM flag -XX:MaxGCPauseMillis actually do, and what happens if you set it to 5 milliseconds on a G1 heap?

## A goal, not a contract The single most important thing to say about `-XX:MaxGCPauseMillis` is that it is a **soft goal**. Nothing in the JVM aborts a collection that overruns it. G1 (and, more weakly, the Parallel collector) treats it as the objective its heuristics optimise toward, and it will regularly miss it — during a full compaction, when a large amount unexpectedly survives, or when the host is starved of CPU. ## How G1 uses it G1 maintains a *pause-time prediction model*: statistics gathered from previous collections about how long it takes to scan roots, copy a given volume of live data, update remembered sets and finish up. Before each collection it uses the model to pick a **collection set** whose predicted cost fits the target: - **Young collections**: G1 adaptively sizes the young generation between `-XX:G1NewSizePercent` and `-XX:G1MaxNewSizePercent` of the heap. A tighter pause target pushes the young generation smaller so fewer regions are evacuated per pause. - **Mixed collections**: after concurrent marking identifies garbage-rich old regions, G1 adds them in batches (bounded by `-XX:G1MixedGCCountTarget` and friends), again sized to fit the target. So the target does not make the collector faster; it changes *how much work it attempts at once*. ## The chain of consequences when the target is too low 1. **More frequent collections.** The same allocation rate against a smaller young generation means more pauses per second. Each pause carries fixed costs — reaching a safepoint, scanning thread stacks and other roots — that do not shrink with the collection set. Total GC overhead rises and throughput falls. 2. **Premature promotion.** A smaller young generation gives objects less time to die before a collection arrives, so more of them survive one collection, then another, and get promoted. Objects that would have died in eden now land in the old generation. 3. **Old-generation pressure.** More promotion means more work for concurrent marking and mixed collections, which the same tight target now forces to be smaller batches. Reclamation can fall behind allocation. 4. **Evacuation failure.** When G1 has no free region to copy survivors into, it falls back to a stop-the-world full compaction lasting hundreds of milliseconds to seconds — vastly worse than the 200 ms default you were trying to beat. That is the irony worth stating in an interview: an aggressive pause target can *increase* worst-case pause time. ## The floor Even with an empty collection set there is irreducible work: reaching a safepoint (time-to-safepoint depends on application threads, not the collector), scanning thread stacks and other roots, and fixed start/end phases. On a large heap with thousands of threads that floor alone can exceed a few milliseconds. Requesting 5 ms does not make roots scan faster; it just makes G1 attempt an impossibly small collection set and keep missing. ## What to do instead - **Start with the default** (200 ms) and measure. Change it only when pause percentiles from GC logs, correlated with your latency SLO, say you must. - **Move in modest steps.** Going 200 → 100 → 50 with a measured workload at each step tells you where throughput starts to hurt and where returns stop. - **Give G1 headroom.** Many pause problems are heap-headroom or allocation-rate problems wearing a costume; a target cannot conjure free regions. - **Change collector when the requirement is structural.** If the SLO genuinely demands single-digit-millisecond pauses at multi-gigabyte heaps, that is ZGC's or Shenandoah's design point — collectors whose pauses are bounded by design rather than by a heuristic target — and you accept their throughput and footprint cost instead. - **Never combine a very low target with a heap that runs near its ceiling.** That is the recipe for continuous evacuation failure. ## On other collectors The Parallel collector accepts `-XX:MaxGCPauseMillis` too and will shrink generations toward it via adaptive sizing, but it has no incremental old-generation mechanism, so its full collection remains proportional to the live set and the target is largely aspirational there. ZGC and Shenandoah do not need it in the same way: their pauses are short by construction, and the tuning lever is instead how aggressively collection is scheduled relative to allocation. Setting a target that conflicts with `-XX:GCTimeRatio` (the throughput goal) simply means the collector cannot satisfy both, and pause tends to win — at throughput's expense.