Understanding the C4 Garbage Collector: A Concurrent Continuously Compacting Collector for Low‑Latency Java Applications

As the fourth installment of Eva Andreasson's JVM performance‑optimization series, this article introduces the C4 garbage collector (Concurrent Continuously Compacting Collector), a novel algorithm implemented in Azul’s Zing JVM that aims to improve scalability for low‑latency enterprise Java applications.

C4’s Concurrency

C4 separates memory reclamation from application allocation, allowing the application to run continuously while the collector compacts the heap concurrently, keeping pause times low regardless of the amount of live data.

Three Phases of C4

Marking – concurrent marking and reference‑tracing identify all reachable objects.

Relocation – live objects are moved together to create large contiguous free regions, effectively performing compaction.

Remapping – references to moved objects are updated in a collaborative manner.

Marking Phase Details

The collector uses concurrent marking and a dirty‑object queue to avoid re‑marking objects that are modified during the marking pass, thereby eliminating the risk of infinite re‑mark loops and OOM errors.

Relocation Phase

Both GC threads and application threads cooperate to move objects. If an application thread accesses an object first, it helps complete the move; otherwise the GC thread performs the relocation. This collaborative approach removes the need for a stop‑the‑world pause.

Remapping Phase

After objects are relocated, GC threads update stale references, while application threads can also assist by correcting references they encounter, ensuring each reference is updated exactly once.

Is C4 Truly Pause‑Free?

During remapping, a thread may be interrupted briefly to update a reference, but the interruption is short‑lived compared with traditional stop‑the‑world pauses, resulting in significantly lower latency.

Evaluation and Comparison

C4 excels when ample memory is available and low pause time is critical, making it suitable for large‑heap servers or deployments with many JVM instances per machine. It is less appropriate for memory‑constrained client applications or workloads that prioritize throughput over latency.

For environments where C4 cannot be used, the article briefly reviews two alternatives:

G1 (Garbage‑First) – a concurrent mark‑and‑sweep collector that partitions the heap into regions and performs incremental pauses; however, it still relies on stop‑the‑world phases and requires extensive tuning.

IBM Balanced GC (BGC) – a region‑based collector for large heaps on 64‑bit platforms; parts of its work are stop‑the‑world, so it shares some latency drawbacks with G1.

Conclusion

C4’s unique combination of concurrent marking, relocation, and collaborative remapping eliminates re‑mark loops, reduces OOM risk, provides continuous compaction without stop‑the‑world pauses, and enables immediate page‑level reclamation, making it a compelling choice for latency‑sensitive, high‑throughput Java services.

When selecting a JVM and GC, developers should weigh the relative importance of pause time versus throughput and consider deployment models (few large‑heap JVMs versus many small‑heap JVMs) to determine whether C4, G1, or BGC best fits their needs.