Understanding the Go Runtime: The Memory Allocator | Hacker News Reader

Understanding the Go Runtime: The Memory Allocator

internals-for-interns.com

100 pointsvalyala16 comments

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

You may also be interested in: https://go.dev/blog/greenteagc

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.

Jesus talks and articles have been very helpful to me.

Three years ago I had no idea how the Go runtime worked, but I very much wanted to learn more. I’m not a software engineer in the conventional sense, so reading the Go source was not a realistic option.

Jesus talks and articles inspired me to learn more. Today I feel comfortable with all stages of the general compiler pipeline. In the past few months I have studied the calculi of the lambda cube, Martin-Lof type theory, Horn-clause-based instruction selection, algorithms for register allocation, Milner’s CCS vs pi-calculus, which structures in compilers and kernels map to digraphs, and so on.

Jesus talks are an excellent onboarding ramp.

Personally I've spent a lot of time coding in go relative to my total time programming

An introduction into topics that are a bit deeper than typical are very interesting to me

It may not make me an expert in the topic reading this, but it at least gives me some new information and if I'd like to know more, I know what to look for.

Before this article if I wanted to know more my searches would be "How does Go memory management work"

Maybe I'm in a minority as this being not trivial information to me though

Personally, I don't like to work with black boxes - I feel more comfortable when I know at least something about layers below the layer of abstraction I'm working on even if I don't need this knowledge directly. Articles like this can make Go runtime less of a black box even if they lack rigor.

It's of interest to anyone who wants to design something similar, for example a toy language, without spending weeks in the golang codebase wrestling with irrelevant go-specific details.

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.

While this is generally true, i found the article well written and without the annoying halmarks of AI writing; if AI was used in editing it was wisely employed.

What if it was a stock photo? Better to actually read the text than go by heder images that are rarely ever anything but stock pictures.

> 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.

"Page" is OS terminology. "Arena" is Go terminology. An arena is made up of sequential pages. Go asks the OS for 64MB of sequential memory, and calls that 64MB chunk an arena; this is consistent with the text you quoted. It is not incorrect.

Cunningham’s Law in action (thanks for the summary)

Thank you, I stand corrected! I must have been tired originally reading this.

Go...

Reply on news.ycombinator.com