Hacker News

Hacker News

Understanding the Go Runtime: The Memory Allocator

96 points by valyala 5 days ago | 14 comments

rjgray 23 hours ago

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

EdNutting 23 hours ago

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

EdNutting 23 hours ago

jeffbee 23 hours ago

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.

willx86 13 hours ago

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

citrin_ru 11 hours ago

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.

kfreds 16 hours ago

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.

kitsune1 24 hours ago

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.

cornholio 15 hours ago

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.

kitsune1 5 hours ago

[dead]

Cthulhu_ 11 hours ago

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.

kitsune1 5 hours ago

[dead]

burntcaramel 24 hours ago

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

mort96 24 hours ago

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

lucketone 18 hours ago

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

pjmlp 17 hours ago

Go...