In the previous article
 we explored how the Go runtime bootstraps itself — how a Go binary goes from the operating system handing it control to your func main() running. During that bootstrap, one of the first things the runtime sets up is the memory allocator. And that’s what we’re going to explore today.
Think of the memory allocator as a warehouse manager. Your program constantly needs boxes of different sizes — sometimes tiny, sometimes huge — and it needs them fast. The allocator’s job is to hand out those boxes as quickly as possible, keep the warehouse organized so nothing goes to waste, and work with the garbage collector to reclaim boxes that nobody is using anymore.

Hacker News is a community-driven platform for sharing and discussing technology news, startups, and programming-related topics. Through user submissions and comments, Hacker News offers insights into emerging technology trends, industry developments, and entrepreneurial ventures. Readers can participate in discussions, share their insights, and stay informed about the latest advancements in technology and innovation.

Hacker News

A deep dive into Go's memory allocator internals. Covers how the runtime avoids frequent OS syscalls by requesting 64MB arenas upfront, subdividing them into 8KB pages and then into spans holding fixed-size slots. Explains the 68 size classes (8B–32KB), the scan/noscan distinction yielding 136 span classes, and the tiny allocator for sub-16-byte pointer-free objects. Details the three-level hierarchy (mcache → mcentral → mheap) that eliminates lock contention for most allocations. Also covers GC integration via dual bitmaps (allocBits and gcmarkBits), lazy sweeping, and the background scavenger that returns unused pages to the OS via MADV_DONTNEED.

Internals for Interns