In Go, what is a garbage-collection mark assist, and which goroutine pays for it?

### The collector runs while your program does Go's garbage collector is concurrent. Once a cycle starts, the runtime walks the pointer graph from its roots — every goroutine's stack, the package-level variables, and a few internal structures — and *marks* every object it can reach, so that afterwards anything unmarked can be reclaimed. That walk happens while your goroutines keep running. Nothing is moved; the program never sees the collector except as CPU time and, briefly, as two very short pauses that bracket the cycle. Marking is CPU work, and the runtime funds it with background mark workers whose total share is capped at roughly a quarter of the process's Ps (the logical processors counted by GOMAXPROCS). That cap exists so the collector cannot starve the application it is collecting for. ### The race the cap creates The cap also creates a race the collector can lose. While marking proceeds, the program keeps allocating, and every new allocation both consumes heap and, if it holds pointers, adds edges to the graph that must be walked. Allocate fast enough and the background workers will not have finished marking by the time the heap has grown to the size at which this cycle was supposed to complete. There is no comfortable way to lose that race: the collector cannot abandon the cycle, and the heap cannot simply keep growing. Go's answer is not to raise the collector's CPU share. It is to make allocation carry the work. When a goroutine allocates during the mark phase, the runtime charges it a proportional amount of scanning and makes it perform that scanning inline, in the allocation path, before the new object is handed back. That inline marking is a **mark assist**. ### Charged at the allocation site Because the charge is applied inside the allocator, the goroutine that allocates is the goroutine that pays. A goroutine parked on a channel receive, blocked in a system call, or looping over a slice it already owns allocates nothing and is never drafted into marking. A goroutine that decodes a fresh object graph on every iteration pays a great deal. This is deliberate. It is backpressure aimed exactly at the cause: the faster a goroutine allocates, the more collector work it is made to do, and the more collector work it does, the slower it allocates. The mechanism is self-limiting, and the limiting force lands on the code producing the pressure instead of being smeared evenly across the process. ### What it looks like from the outside Three things surprise people the first time they meet it. 1. **The time is attributed to your own code.** In a CPU profile the assist shows up as `runtime.gcAssistAlloc` and the marking routines beneath it, sitting directly under whichever function performed the allocation. The natural reading is "my decoder got slower", and the decoder did not change at all. 2. **The cost is bursty and uneven.** Assists happen only during a mark phase, and only when background marking is behind. Two identical requests can cost very different amounts depending on when they arrive, which moves the tail of a latency distribution far more than it moves the mean. 3. **The payer is frequently not the culprit.** Allocation rate is a property of the whole process. A cheap request path sharing a process with an expensive one will be charged assists it did nothing to cause. ### It is not a pause A mark assist is not a stop-the-world pause, and conflating the two is the most common mistake on this topic. A stop-the-world pause suspends every goroutine in the process; Go has two short ones per cycle and they exist for separate reasons. An assist blocks exactly one goroutine — the one that allocated — and only until it has scanned what it owes, after which its allocation completes and it carries on. Nothing else in the program stops. That distinction matters practically: assist-driven latency is fixed by allocating less, while pause-driven latency is a different problem with different remedies. ### Why not just run more background workers? Two reasons. First, extra background workers take CPU from the program with no relationship to who is causing the pressure — a quiet goroutine would be slowed down to pay for a noisy one. Second, an uncapped collector can consume an arbitrary share of the machine, which is precisely the failure mode the budget exists to prevent. Charging the allocator ties cost to cause and keeps the background budget honest. ### The one-sentence version Go budgets background marking so it cannot starve the program, and closes the resulting shortfall by billing it to whoever is allocating — so the busiest allocator pays for the marker's backlog.