The Memory Allocator

Why not just call the OS?

Asking the operating system for memory on every new would be catastrophically slow — a syscall, a lock, and kernel bookkeeping per allocation. Instead Go (like other modern runtimes, drawing on TCMalloc) keeps its own allocator that requests big chunks from the OS rarely and hands out small pieces constantly. Two ideas make the common path nearly free: size classes and a tiered, mostly-lock-free cache.

Size classes: ~70 standard sizes

Rather than allocating the exact number of bytes requested, Go rounds each request up to one of about 70 fixed size classes — 8, 16, 24, 32, 48, 64, … bytes. Each class has its own pools, so allocating is just “pop the next free slot of class N” — O(1), no scanning the heap for a hole that fits.

The cost is internal fragmentation: a 33-byte object occupies a 48-byte slot, wasting 15 bytes. The benefit is speed and low external fragmentation. Objects larger than 32 KB skip the size-class machinery and are allocated directly from the heap as “large objects.”

graph LR
R["request: 33 bytes"] --> C["round up to<br/>size class: 48 bytes"]
C --> S["take a free 48-byte slot<br/>from a span"]

The three tiers

A heap allocation walks a hierarchy, stopping as soon as it finds free space. The first tier is per-P and needs no lock; only misses pay for synchronization.

graph TD
A["allocate object of size class N"] --> M["mcache (per-P)<br/>lock-free fast path"]
M -->|"empty for class N"| Ce["mcentral[N]<br/>(shared, locked)"]
Ce -->|"no free span"| H["mheap<br/>(global, page-level)"]
H -->|"out of pages"| OS["ask the OS<br/>(mmap)"]

• mcache — each P (scheduler processor) owns one. It holds a span per size class. Allocation pops a free slot with no lock, because only the owning P touches it. This is the overwhelmingly common path.
• mcentral — one per size class, shared across all Ps. When an mcache runs out of a class, it grabs a fresh span here (briefly locked).
• mheap — the global heap. It manages memory in 8 KB pages, carves them into spans (runs of pages assigned to one size class), and asks the OS (mmap) for more when it runs dry.

The tiny allocator

Many programs allocate swarms of tiny, pointer-free values — a one-character string, a boxed int, a small []byte. Giving each its own 8- or 16-byte slot wastes space and slot count. The tiny allocator packs several such sub-16-byte, pointer-free objects into a single block, bumping a small offset within it. They must be pointer-free so the GC can scan the shared block as one unit.

Watching the allocator work

You can’t poke the mcache directly from Go, but MemStats exposes the shape of what the allocator is doing — object counts, live heap, and how many size-class objects exist:

package main

import (
"fmt"
"runtime"
)

func snapshot(label string) {
var m runtime.MemStats
runtime.ReadMemStats(&m)
fmt.Printf("%-7s HeapAlloc=%4d KB  Mallocs=%d  Frees=%d  HeapObjects=%d\n",
	label, m.HeapAlloc/1024, m.Mallocs, m.Frees, m.HeapObjects)
}

func main() {
snapshot("start")

// Allocate many small objects of the same size class.
keep := make([][]byte, 0, 50_000)
for i := 0; i < 50_000; i++ {
	keep = append(keep, make([]byte, 24)) // rounds to the 24- or 32-byte class
}
snapshot("after")

// Drop references and force a GC so Frees climbs.
keep = nil
runtime.GC()
snapshot("gc")
_ = keep
}

Mallocs jumps by ~50,000 during the loop; after dropping the slice and running the GC, Frees catches up and HeapObjects/HeapAlloc fall. Each of those allocations took the lock-free mcache path the vast majority of the time.

Reference

See also

• the stack & the heap — only heap allocations reach the allocator.
• escape analysis — what decides an allocation is a heap allocation.
• the garbage collector — reclaims the spans this allocator hands out.
• memory layout & alignment — shrink types to land in smaller size classes.

Next: how all this heap memory gets reclaimed — the garbage collector.

Related topics