The garbage collector: why pauses do not grow with the heap, and GOGC speeds up nothing

What is really being asked

There are almost always three questions, and they escalate:

1. "What kind of collector does Go have?" — they are checking whether you say the word "concurrent" rather than only "mark and sweep".
2. "How long are the pauses and what do they depend on?" — this is where most people break: the pause gets confused with the cost of collection.
3. "How do you tune it?" — and the right answer starts with "usually you don't", then goes on to what each knob actually charges you.

The topic has a single spine: Go's collector is optimised for latency, not for throughput. It is willing to spend more CPU time as long as it does not stop the program for long. Everything else is a consequence.

Base: what the collector actually does

Before counting pauses and turning knobs it is worth naming the problem. It is short and contains no Go terminology at all:

Find the objects the program can no longer reach, and give their memory back.

"Can no longer reach" is the key phrase — and it means not "will not use" but unreachable by references:

The collector does not know whether an object is "needed". It only knows whether there is a path to it from the roots. Two consequences follow immediately and explain everything after: an object with one forgotten reference lives forever (that is what a leak in Go is), and the collector's work is proportional to the number of LIVE objects, not of garbage — it never touches the garbage at all.

Notice what the statement does not contain. Not a word about when the collector arrives, how long it works, or whether it stops the program. Those are all questions about machinery, and different collectors — and different versions of one collector — answer them differently.

That is already enough to answer the basic interview question: the collector looks for the unreachable and gives its memory back, rather than tracking what the program "might still want". Everything below is about how it manages to do that while barely stopping the program, and what that costs.

Mechanism 1: a whole collection cycle

Now for that machinery — how the collector walks everything reachable without taking the CPU away from the program for long. A cycle has four phases, and the world stops in only two of them, briefly:

▐ mark setup                    world stopped, microseconds
█████████ concurrent marking      the program RUNS, the walk goes in parallel
▐ mark termination              world stopped, microseconds
█████████ sweeping                the program runs, memory is returned

Everything the lesson goes on to check by measurement follows from this picture: the pauses are the two narrow strips, the work is the two wide ones, and they grow differently.

For marking to run alongside the program a write barrier is needed: while marking is under way every pointer write goes through it, and the barrier stops the program hiding a not-yet-visited object from the collector. That is the tax of concurrency — a standing surcharge on CPU time in exchange for a short pause.

Mechanism 2: what does not grow with the heap

The central claim of the topic is worth checking first:

A run of bench/gogc/internals.go prints:

The heap grew sixteenfold — the pause did not: ×1.22 against ×16. This is the very property the collector is shaped for: it runs alongside the program and stops it twice per cycle, briefly — to set marking up and to finish it.

It is worth saying separately what exactly was measured. PauseNs from MemStats is the time the world is stopped, not the duration of a cycle. The duration of a cycle does grow with the heap — but the program keeps working through it.

And a caveat about the honesty of the numbers: the measurement ran on two cores and on one particular version of the runtime, so the absolute microseconds mean nothing. Only one thing matters here — that the column does not grow. And that property itself belongs to an implementation rather than to the language: the collector has changed from version to version and will change again, which is why both its behaviour and the number of threads allowed to execute code are quoted together with a Go version rather than as a universal law.

The last row of the table is not a typo but the resolution of the instrument. It is the same measurement at the same 16 MB, taken once more: 54 µs against 39. The gap between two repeats of ONE size turned out to be larger than the difference between 16 and 256 MB — which means the direction of change cannot be discussed from this table at all. It answers exactly one question: does the pause scale with the heap. The answer is no: heap ×16, pause ×1.22.

Why that row is there. A median of a small sample on two cores jumps from run to run by more than the rows of the table differ, and without a repeat beside them a direction is easy to read out of such numbers — and to read wrongly. So the sample here is two hundred cycles, the repeat is printed alongside, and the run itself prints whether the difference between rows is resolvable by its own instrument.

Had the measurement printed the maximum instead of the median, it would be worse still: a table of maxima may well show the pause falling as the heap grows. The cause would not be the collector: the maximum of a small sample on a two-core machine is the worst other process on it. The median answers the question that was asked; the maximum answers a different one.

So what does grow? The work of marking: the more live objects there are, the more pointers must be walked. That shows up in the share of CPU time, not in the pause. And confusing the two is expensive — the program gets tuned for a quantity that never changed.

Mechanism 3: GOGC — not an accelerator but a trade knob

The guide defines it by a formula, and that matters: there is no absolute size in it, there is a ratio.

The run confirms the arithmetic and shows the price:

The table has to be read across two columns at once. The work is the same in every row — two hundred thousand kilobyte allocations against sixteen megabytes of live data. At GOGC=400 there are eight times fewer cycles than at 50 — and a peak heap three times higher.

That is not a speed-up but a transfer of the cost from time to memory. Hence the rule for choosing: raise GOGC when memory is plentiful and a profile shows time going into collection; lower it when memory is tight. There is no "good default" here; there is only whichever resource the system has more of.

And here is what GOGC does not have: a ceiling. The target is computed from the live data, so as the live set grows, so does the target. A program with a growing cache will eat all the memory without ever violating the setting.

Mechanism 4: GOMEMLIMIT — the ceiling, and why it is soft

The measurement shows the difference directly:

The second row is that missing ceiling. The fourth is what GOMEMLIMIT adds: the target stops rising above the limit, and collection starts running more often to keep the program under it.

The word "soft" in the documentation is not there for politeness:

If the live data itself outgrows the limit, collection cannot bring memory below it: there is nothing to collect, everything is reachable. Without a safeguard the runtime would collect almost continuously — the guide calls this a death spiral — and right after that warning the guide describes the safeguard: a limiter on GC CPU time.

In the go1.24.7 source (runtime/mgclimit.go) the limiter is a "leaky bucket" holding one CPU-second per P: it fills with GC time and drains with program time, and the comment in the source calls the resulting threshold "a very conservative limit of 50%". When the limiter kicks in, the runtime trades memory for CPU: collection stops keeping up with the limit, and the heap goes past it. The debug.SetMemoryLimit documentation of the same version speaks of this regime cautiously: collection may run nearly continuously, "however, the application may still make progress". So the process will not necessarily freeze — but it will not necessarily survive either: having exceeded the soft limit, it can run into the real one.

Two practical recommendations follow, and they are the ones interviewers want to hear. Set the limit below the container's real boundary, with headroom. GOMEMLIMIT accounts only for memory managed by the Go runtime — not the binary itself, not memory of C code, not syscall.Mmap — and the limiter may let the heap step over it; without headroom the external boundary fires and the process is killed by OOM. And do not set GOMEMLIMIT in place of GOGC: they do not replace each other. GOGC governs the normal regime, GOMEMLIMIT insures the edge.

Deeper: why the collector is the way it is

Three decisions, asked about at the more senior levels.

Non-generational. The generational hypothesis ("most objects die young") does hold in Go — but its benefit has already been collected by escape analysis: short-lived objects mostly never reach the heap at all, they stay on the stack. A young generation would be half empty, while its barriers would cost on every pointer write.

Non-moving. Objects do not move, so addresses are stable — which makes interoperating with C cheap and allows unsafe.Pointer to exist at all. The price is fragmentation, handled by a size-class allocator instead of by compaction.

Concurrent, with a write barrier. Marking runs alongside the program, and so that the program cannot hide an object from it, every pointer write during marking goes through a barrier. That is the collector's standing tax on CPU time — the same trade of more CPU for a shorter pause.

And the thing mistaken for a leak. The collector does not return freed memory to the OS immediately: pages go back gradually, in the background.

Four quantities that get merged into one, after which people argue about the readings:

RSS is always larger than HeapAlloc, and that is normal: it includes pages taken but not yet returned, goroutine stacks, allocator metadata and the code. A leak looks different — HeapAlloc grows after a full collection.

And the link to the previous lesson. Fewer heap allocations means fewer live objects means less work for marking. But that is not an optimisation rule: escape analysis has already filtered out most of the short-lived, and rewriting code for the stack almost always makes it longer and more brittle. Profile first, then decide — the same order as in the escape-analysis lesson.

How to answer in an interview

The short answer: the collector gives back the memory of objects with no path left to them from the roots, and it does that alongside the program — stopping it twice per cycle and briefly. Which is why the pause is short and does not depend on heap size: 16 and 256 megabytes of live data gave me 39 and 48 microseconds — 1.22× on a sixteenfold heap. What grows is not the pause but the work of marking — the share of CPU time, and that is exactly what gets confused with the pause.

That is enough to answer correctly. Beyond it is what you add when the interviewer digs.

If the interviewer digs deeper

Name the properties rather than the acronym — and tie them to a version. "In current versions of Go it is a concurrent tri-colour mark-and-sweep collector, non-moving and non-generational. Optimised for latency: willing to spend more CPU so as not to stop the program for long. The language promises none of that — they are properties of the implementation."

On GOGC say the word 'trade'. "It sets how far the heap may grow beyond the live data. GOGC=400 gave me four times fewer cycles and a two-and-a-half times larger peak heap. Collection does not get cheaper."

Name what GOGC lacks. "A ceiling. The target is computed from the live data, so a growing cache will eat the memory without violating the setting. The ceiling is GOMEMLIMIT, and it is soft."

And finish with what not to do. "Turning knobs without a profile is not worth it: on ordinary workloads the collector costs single-digit percentages of CPU. Removing allocations is cheaper than tuning their cleanup."

And one caveat that is easy to overdo: the numbers here are not constants of the language. The pause microseconds were taken on one runtime version and on two executing threads, and on another machine they will be different. The precise wording is this: what you memorise is not the values but which quantity depends on what — the pause does not depend on heap size, the work of marking does, and GOGC is paid for in memory.

Next they ask

Common misconceptions

Practice

Two problems. Answer first, then check against the real output: in both, the correct answer comes from a run of the script, not from an assertion.

fmt.Println(debug.SetGCPercent(100))

fmt.Println(round(goalOverLive(100)))
fmt.Println(round(goalOverLive(400)))

fmt.Println(cyclesFor(-1))

debug.SetGCPercent(-1)
var a runtime.MemStats
runtime.ReadMemStats(&a)
runtime.GC()
runtime.GC()
var b runtime.MemStats
runtime.ReadMemStats(&b)
fmt.Println(b.NumGC - a.NumGC)

100
2
5
0
2

0
1
4
0
2

100
1
4
0
0

100
2
5
1
2

Knowledge check