Performance
GC: multiple-choice review
Crux Multiple-choice synthesis across the GC unit — allocation pressure, pacing, collector tradeoffs, barriers, and production failure modes.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each one mirrors a decision you make in a real incident — not a definition to recite, but a tradeoff to weigh under load.
Goal
Confirm you can connect allocation pressure, collector choice, tuning knobs, and production failure modes — the synthesis the individual lessons built toward.
Quiz
Completed
Service A holds a 4 GB cache and allocates 50 MB/s. Service B holds 100 MB live and allocates 1 GB/s. Both run the same collector. Which sees more GC-driven tail latency, and why?
Heads-up Marking cost scales with the LIVE set, and a steady cache is mostly stable live data collected rarely. Cycle frequency — driven by allocation rate — dominates tail latency here.
Heads-up Same collector, very different allocation profiles. The collector algorithm sets the pause shape; the allocation rate sets how often you pay it.
Heads-up GC pauses are a primary tail-latency source in allocation-heavy services; that is the entire premise of the unit.
Quiz
Completed
A Go service in a 4 GB container OOM-kills sporadically under traffic spikes; GOGC is the default 100. What is the first knob, and what does it actually do?
Heads-up GOGC=50 triggers GC at a lower growth ratio but enforces no ceiling — a large enough spike still grows the heap past the container limit and OOMs.
Heads-up GOGC=off disables the proportional trigger entirely; the heap only grows. That is safe only for short batch jobs that exit, never for a long-running service.
Heads-up ZGC is a JVM collector; this is Go. The root cause is a missing soft memory cap, not the collector algorithm.
Quiz
Completed
After migrating from G1 to (non-generational) ZGC, pauses drop from 60 ms to under 1 ms, but throughput falls ~12% and RSS rises ~18%. How do you read this?
Heads-up No collector minimises pause, throughput, and memory simultaneously. Those numbers are within normal non-generational ZGC overhead.
Heads-up Barrier overhead directly taxes CPU throughput, and colored-pointer multi-mapping inflates memory. Both are collector-determined.
Heads-up If the workload is latency-sensitive on a large heap, trading 12% throughput for 60×-lower pauses is often the intended win. Judge against the SLO, not the throughput number alone.
Quiz
Completed
Why does a concurrent collector need a write barrier, and what breaks without one?
Heads-up The barrier adds per-write overhead (2–10% CPU); it does not parallelise marking. Its job is correctness during concurrent mutation, not speed.
Heads-up Compaction is a separate phase. The write barrier is about not losing live objects when the mutator rewires references mid-mark.
Heads-up Any concurrent collector needs it, generational or not — Go is non-generational and still uses a write barrier.
Quiz
Completed
A Java service that registers Object.finalize() on file-handle wrappers shows open-handle counts spiking unpredictably under load. Root cause?
Heads-up The OS assigns descriptors correctly; the non-deterministic release through finalizer timing is the proximate cause.
Heads-up Heap size does not control finalizer-thread scheduling. Finalizers are simply the wrong mechanism for deterministic resource release.
Heads-up They are still collected — but only after their finalizer runs, which is exactly the delay that pins the handles.
Quiz
Completed
gctrace shows GC CPU climbing 1% → 39% over an hour while concurrent-mark time grows from 1.3 ms to ~350 ms. What is happening and what is the first fix?
Heads-up A healthy service holds GC CPU under ~5%. A monotonic climb to 39% with growing mark time is pathological, not warm-up.
Heads-up Deferring GC trades memory for fewer cycles and can push you into OOM during a spiral; it masks the cause. Reduce allocations first, then consider tuning.
Heads-up More cores delay the OOM but the spiral resumes as allocation pressure scales with load. The durable fix is fewer allocations.
Recap
Across the unit the through-line is one decision tree: allocation rate sets GC frequency, the live set sets cycle cost, the collector sets pause shape, and the knobs (GOMEMLIMIT first, GOGC/pause-target second, algorithm last) defend the bounds. Production failures — OOM under spikes, ZGC tradeoffs, finalizer storms, death-spirals, allocation DoS — all resolve back to the same lever: reduce allocations before you tune anything.