Concurrent GC

Learn how GC runs concurrently with the application.

Concurrent GC

Go's GC marks concurrently with the program. The world stops only for two brief moments (STW): when marking turns on and when it finishes. During marking about 25% of CPU goes to the GC; goroutines that allocate a lot are also forced to help through "mark assist".

GODEBUG=gctrace=1 ./app
# gc 12 @3.1s 2%: 0.03+1.2+0.02 ms clock, ...
#                 STW   conc. STW

The write barrier

If the program writes to a pointer field during marking, a short piece of code inserted by the compiler runs and paints the target object grey. Go uses a hybrid barrier (Yuasa + Dijkstra); thanks to it goroutine stacks don't need rescanning at the end of marking, keeping the second STW very short.

Exercise Pause time

Call runtime.GC(), then read the last pause with runtime.ReadMemStats: m.PauseNs[(m.NumGC+255)%256]. Print whether the pause was shorter than one second (< 1e9).

Show example solution

package main

import (
    "fmt"
    "runtime"
)

func main() {
    runtime.GC()
    var m runtime.MemStats
    runtime.ReadMemStats(&m)
    son := m.PauseNs[(m.NumGC+255)%256]
    fmt.Println(son < 1e9)
}

Test yourself

When is the write barrier active?
- Always
- Only during STW
- Never
- Only during the mark phase
Show answer

Only during the mark phase — The barrier watches pointer writes while marking runs; when the GC isn't running it is off and costs nothing.

GC trace

GODEBUG=____=1 ./app

Show answer

GODEBUG=gctrace=1 ./app

GC phase

STW 1

Turn marking on
Concurrent marking

While the program runs
STW 2

Finish marking
Sweeping

Lazy, during allocation

Next lesson: GOGC and GOMEMLIMIT

We Are Enhancing Your Experience

Cookie Preferences

Strictly Necessary Cookies

Analytical Cookies