Low-Pause Concurrent-Compaction Collector (Shenandoah)

## The problem Shenandoah solves Moving collectors give you compaction, which eliminates fragmentation and makes allocation a pointer bump. The traditional price is that objects can only move while the application is stopped — otherwise a thread could read a reference to an object that has just been relocated and act on a stale copy. That is why classic collectors do evacuation inside a stop-the-world pause, and why their pauses grow with the amount of live data they must copy. Shenandoah removes that coupling by making **evacuation concurrent**. Application threads and the collector run at the same time while objects are being relocated, coordinated by barriers the JIT compiler inserts into application code. ## Region-based heap The heap is divided into equal-sized regions (the size is derived from heap size, or set with `-XX:ShenandoahRegionSize`). Each region is entirely free, entirely in use, or part of a **collection set** chosen for evacuation. Regions with the most garbage are chosen first — collecting them yields the most free space for the least copying. Regions that turn out to contain no live objects at all are simply reclaimed outright without copying anything, which is often a large share of the win. Regions also mean the collector can bound its own work: it decides how many regions to include in a cycle instead of being forced to process the whole heap at once. ## Where the pauses are One cycle contains a few short stop-the-world points, and each does work proportional to the **root set** rather than the heap: - **Init Mark** — stop threads, scan their stacks and other roots, set the global GC state so barriers become active. - **Final Mark** — drain the buffers that recorded concurrent mutation, finish marking, choose the collection set, evacuate the objects directly referenced by roots. - **Init/Final Update References** — short checkpoints that bound the reference-rewriting phase and recycle the evacuated regions. Everything between those points — concurrent marking, concurrent evacuation, concurrent reference updating, concurrent cleanup — runs while the application runs. ## Why "independent of heap size" is precise but narrow The claim is about **pause duration**, not about total collector work. Roots are thread stacks, static fields, JNI handles and similar; their size grows roughly with the number of threads, not with how much data the application keeps. So doubling the heap does not double the pause. Concretely, teams typically see pauses in the single-digit millisecond range across very different heap sizes. But concurrent work is still proportional to live data, and it is paid in two currencies: - **CPU**: collector threads run alongside the application, so a share of the machine's cores is spent on GC while requests are being served. - **Throughput**: the barriers that make concurrent movement safe execute on ordinary application code paths, costing a percentage of application throughput even when no GC is in progress. A collector cannot make work disappear; it can only move it out of the pause. Shenandoah trades throughput and CPU for latency, which is the right trade for latency-sensitive services and the wrong one for batch jobs maximising throughput. ## Availability and configuration Shenandoah appeared as an experimental collector in JDK 12 (JEP 189) and became a production feature in JDK 15 (JEP 379); it was also backported to JDK 11 in several distributions. It is built into most OpenJDK builds but has historically been omitted from some vendor builds, so "is it in this JDK" is a real first question — `java -XX:+UseShenandoahGC -version` answers it immediately. A generational mode was added later (JEP 404, `-XX:ShenandoahGCMode=generational`), which collects young objects more cheaply and reduces the collector's CPU cost on typical workloads. Basic operation needs very little configuration: choose the collector, set a heap, and log GC. The main levers are heap size (headroom for concurrent evacuation), the heuristic that decides when to start a cycle, and the number of concurrent GC threads. ## When to reach for it Use it when the tail latency of stop-the-world compaction is the problem you actually have: interactive services, trading and bidding systems, low-latency APIs with large or growing heaps. Do not reach for it to fix an application that is simply allocating too much or leaking — a concurrent collector will lose the race against a runaway allocation rate and fall back to stop-the-world work, which is worse than where you started.