GC tuning: pacing, heap shape, and allocation observability

A Go service is containerised with a 4 GB limit. GOGC is left at the default 100. Under traffic the heap grows to 3.8 GB, the pacer triggers frantic GC cycles, and the pod OOMs. Adding GOMEMLIMIT=3600MiB stops the OOM — no code change, no collector swap.

Pacing and the soft memory limit

Modern collectors pace themselves: they predict when the next GC cycle needs to start so it finishes before the heap is exhausted. Go’s pacer (redesigned in 1.18, refined in 1.19 with GOMEMLIMIT) blends two signals — heap-growth rate and GC CPU share — into a closed-loop controller. JVM G1’s pause-time goal directs its pacer toward keeping pauses under a target.

Go knobs:

• GOGC=100 (default) — run GC when live bytes double since the last cycle. Increase to defer GC (use more memory, cycle less often); decrease to cycle more often (use less memory, more CPU).
• GOMEMLIMIT — soft cap on total memory the runtime should use. The pacer becomes more aggressive as the process approaches the limit, trading throughput for memory-bound compliance. For containerised services, set to ~90% of the container’s memory limit.

JVM knobs:

• -Xmx — hard heap ceiling.
• -XX:MaxGCPauseMillis=N — G1 targets N ms pauses by adjusting region sizes and collection frequency. Set too low and G1 over-collects, hurting throughput. Set too high and you get the occasional 200 ms spike.

Heap shape and the live-set distinction

Total heap (RSS) is not the same as live set — the bytes that are actually reachable. A 4 GB RSS may have only 800 MB live; the remaining 3.2 GB is garbage pending the next cycle, or fragmentation, or runtime-reserved arenas.

Marking time is proportional to live bytes, not total RSS. GC cycle frequency is proportional to allocation rate. Sizing the heap to ~1.5–2x the live set is the canonical tuning target: smaller ratios trigger excessively frequent GC; larger ratios waste memory without a proportional latency win.

Workloads with large fluctuating live sets (in-memory caches, large aggregations) need a higher ratio. Small, steady-state services run fine at the lower end.

Allocation observability per runtime

Without per-runtime instrumentation you diagnose blind.

Go: runtime/metrics package + /debug/pprof/allocs scrape every 30 s. Wire alloc_bytes_total and alloc_objects_total rate into Prometheus. GODEBUG=gctrace=1 logs every cycle to stderr — useful in dev, noisy in prod.

JVM: -Xlog:gc*:file=gc.log:time,uptime,level,tags for rotation-ready GC logs. JFR ObjectAllocationInNewTLAB events for allocation profiling. Micrometer exposes gc_pause_seconds histogram and gc_memory_allocated_bytes_total rate to Prometheus.

V8 / Node: process.memoryUsage().heapUsed polled every 15 s; v8.getHeapStatistics() for a richer view. perf_hooks.PerformanceObserver with 'gc' type captures every pause event programmatically.

.NET: GC.GetTotalAllocatedBytes() rate + dotnet-counters monitor for live readout of gen-0-gc-count, gen-1-gc-count, gen-2-gc-count, and alloc-rate.

The cross-runtime alert pattern: alloc rate trending above the service-specific threshold (typical 300–500 MB/s/core) for more than 5 minutes triggers investigation. Pair alloc rate with p99 on one chart — when they diverge, GC is the suspect.

Object pooling: when it works and when it doesn’t

Pooling reuses allocations to reduce GC pressure. Works well for objects that are expensive to create, used briefly on hot paths: bytes.Buffer, JSON encoders, regexp objects, scratch slices.

Pooling fails when:

• Objects are cheap to create (pool overhead exceeds savings).
• Objects are long-lived (pool holds memory without freeing).
• Thread-coordination cost exceeds allocation cost.

Go’s sync.Pool has an advantage: the GC can drain the pool between cycles, so memory is not locked forever. JVM and .NET object pools hold memory until explicit release — audit their max-pool-size.

The senior rule: pool only what the profile flags as a hot allocation site. Don’t pool preemptively.