> We said the runtime asks the OS for large chunks of memory. Those chunks are called arenas, and on most 64-bit systems each one is 64MB (4MB on Windows and 32-bit systems, 512KB on WebAssembly).

Incorrect. You ask the OS for pages. (Golang does internally appear to manage its heap into “arenas”.) On WebAssembly the page size is 64KiB. Window 64-bit it’s 4KiB, Apple Silicon 16KiB, Linux x86_64 4KiB.

If an article starts with a generated image, I don't read it. It's a signal to me that's it's more likely the rest is generated too.

I found https://nghiant3223.github.io/2025/06/03/memory_allocation_i... to be another excellent resource on this topic.

I don't see why this would be of interest to anyone. It doesn't introduce the topic with enough rigor to prepare someone to work on the runtime itself, and for everyone else it's just trivia. I think if someone wanted to write an article like this of general interest they should focus on observable behaviors of the application, such as the fact that the Go allocator (like its cousin tcmalloc) uses prctl to set the name of its maps, so you can see low-level details of allocation behavior in /proc/smaps, and that it is automatically hugepage-aware, which can help reduce TLB misses, increasing IPC.

See also: https://go.dev/blog/greenteagc