Production GC Implementations: JVM, Go, and .NET

JVM Garbage Collectors
G1 (Garbage First): Default since Java 9. Region based, generational, concurrent. Target pause time configurable (default 200ms). Good balance of throughput and latency for most workloads. Handles heaps up to hundreds of GB.
ZGC: Ultra-low latency collector. Pauses under 1ms regardless of heap size. Uses colored pointers and load barriers. Suitable for terabyte heaps. Higher CPU overhead than G1 but predictable latency.
Shenandoah: Similar goals to ZGC with different implementation. Concurrent compaction via forwarding pointers. Available in OpenJDK. Also achieves sub-millisecond pauses for large heaps.
Go Garbage Collector
Go uses a concurrent, tri-color mark and sweep collector. No generational hypothesis. All objects treated equally. Pauses under 1ms for most workloads, achieved through concurrent marking and write barriers.
Go prioritizes low latency over throughput. The collector targets 25 percent CPU overhead. Heap grows to maintain this target. More memory reduces collection frequency. Trade-off is memory usage for pause time.
.NET Garbage Collector
.NET uses generational collection with three generations. Generation 0 collects most frequently, Generation 2 least. Server mode uses one heap per core for parallelism. Workstation mode uses a single shared heap.
Large object heap (LOH) holds objects over 85 KB. LOH is not compacted by default, leading to fragmentation. .NET 5 added LOH compaction option but it is expensive. Avoid frequent large allocations to prevent LOH growth.
✅ Best Practice: For JVM latency critical services, evaluate ZGC or Shenandoah. For Go services, tune GOGC to balance memory and CPU. For .NET, use server mode and monitor LOH size to catch fragmentation early.

💡 Key Takeaways

✓JVM G1: region-based default, 200ms target pause, good general purpose choice

✓JVM ZGC and Shenandoah: sub-millisecond pauses for terabyte heaps

✓Go GC: concurrent mark-sweep, no generations, 25% CPU target, trades memory for latency

✓.NET: three generations plus large object heap that can fragment

✓Choose collector based on workload: batch uses throughput focus, services use latency focus

📌 Interview Tips

1For JVM latency requirements, compare G1 (200ms pause target) vs ZGC (sub-1ms regardless of heap)

2Explain Go GC trade-off: grows heap to keep collection overhead at 25% CPU, uses more memory for lower latency

3When discussing .NET performance, mention LOH fragmentation risk with objects over 85 KB

← Back to Garbage Collection Fundamentals Overview