Golang's big miss on memory arenas • Hacker News Board

Re: Golang's big miss on memory arenas

#51

Post by dmpk2k » Wed, Dec 10, 2025, 7:57 PM UTC

tpolzer wrote: post #19

I wonder whether it would be possible to retrofit Arena allocation transparently (and safely!) onto a language with a moving GC (which IIUC Go currently is not): You could ask the programmer to mark some callstack as arena allocated and redirect all allocations to there while active and move everything that is still live once you leave the arena marked callstack (should be cheap if the live set is small, expensive bu…

They added arenas to SBCL recently. SBCL has a moving GC, and the Common Lisp spec was finalized in the 1990s.

Okay, this is just Lisp being Lisp, but it's still an example...

Re: Golang's big miss on memory arenas

#52

Post by 9rx » Wed, Dec 10, 2025, 7:58 PM UTC

andrewcamel wrote: post #44

Philosophical question, but after reaching critical mass, should languages even aspire to more? I.e. do you risk becoming "master of none"? What's wrong with specialist languages? I.e. best of breed vs best of suite? I agree with author Go is getting squeezed, but it has its use cases. "COBOL of could native" implies it's not selected for new things, but I reach for it frequently (Go > Java for "enterprise software"…

> should languages even aspire to more?

Some should, maybe. But Go said right from day one that it doesn't aspire to be anything more than a language that appears dynamically-typed with static-type performance for the creation of network servers. It has no reason to. It was very much built for a specific purpose.

It has found other uses, but that was a surprise to its creators.

> Go is getting squeezed

Is it? I don't really see anything new that is trying to fill the same void. There are older solutions that are still being used, but presumably more would use them if Go hadn't been invented. So it is Go doing the squeezing, so to speak.

Re: Golang's big miss on memory arenas

#53

Post by PKop » Wed, Dec 10, 2025, 8:03 PM UTC

btown wrote: post #47

tptacek wrote: post #29

Earlier quoted context omitted.

There was never a proposal to automate arenas in Go code, and that wouldn't even make sense: the point of arenas is that you bump-allocate until some program-specific point where you free all at once (that's why they're so great for compiler code, where you do passes over translation units and can just do the memory accounting at each major step). (Yes: I used arenas a lot when I was shipping C code; they're a very e…

I'm not sure what the parent posters were referring to, but there's an interesting way in which "automation" might make sense in some languages: implicit arena utilization based on the current call stack, without needing to pass/thread an explicit `arena` parameter through the ecosystem. One could imagine a language that allows syntax like CallWithArena(functionPointer, someSetupInfo) and any standard library allocat…

Basically what Odin does yea?

Re: Golang's big miss on memory arenas

#54

Post by btown » Wed, Dec 10, 2025, 8:08 PM UTC

PKop wrote: post #53

btown wrote: post #47

Earlier quoted context omitted.

I'm not sure what the parent posters were referring to, but there's an interesting way in which "automation" might make sense in some languages: implicit arena utilization based on the current call stack, without needing to pass/thread an explicit `arena` parameter through the ecosystem. One could imagine a language that allows syntax like CallWithArena(functionPointer, someSetupInfo) and any standard library allocat…

Basically what Odin does yea?

Hadn’t known about Odin but yes!

> Operations such as new, free and delete by default will use context.allocator, which can be overridden by the user. When an override happens all called procedures will inherit the new context and use the same allocator.

https://pkg.odin-lang.org/core/mem/

Re: Golang's big miss on memory arenas

#55

Post by Yokohiii » Wed, Dec 10, 2025, 8:21 PM UTC

andrewcamel wrote: post #44

Philosophical question, but after reaching critical mass, should languages even aspire to more? I.e. do you risk becoming "master of none"? What's wrong with specialist languages? I.e. best of breed vs best of suite? I agree with author Go is getting squeezed, but it has its use cases. "COBOL of could native" implies it's not selected for new things, but I reach for it frequently (Go > Java for "enterprise software"…

Look at PHP. Every year people say PHP got much better then in the dark ages.

Yes it got rid of it's rough edges. People solely look positive at it because it has become more familiar with mainstream OOP languages. But it has no identity anymore. It is still simpler for the web then most competitors, but it doesn't matter because you install 30 packages for an hello world anyway. The community doesn't want simplicity, they want easy, with glorious looking code.

The irony is that PHP is perceived more attractive by coders, but it's so generic now, that a newbie is unlikely to choose it.

Re: Golang's big miss on memory arenas

#56

Post by Pet_Ant » Wed, Dec 10, 2025, 8:33 PM UTC

> The real reason was the “Infectious API” problem. To get performance benefits, you can’t just create an arena locally; you have to pass it down the call stack so functions can allocate inside it. This forces a rewrite of function signatures.

Sorry, but it doesn't seem that difficult (famous last words). Add a new implicit parameter to all objects just like "this" called "thisArena". When a call to any allocation is made, pass "thisArena" implicitly, unless something else passed explicitly.

That way the arena is viral all the way down and you can create sub-arenas. It also does not require actually passing the arena as parameter.

You don't even need to rewrite any new code, just recompile it.

Re: Golang's big miss on memory arenas

#57

Post by kgeist » Wed, Dec 10, 2025, 8:41 PM UTC

>Instead of asking the runtime for memory object-by-object, an Arena lets you allocate a large pool of memory upfront. You fill that pool with objects using a simple bump pointer (which is CPU cache-friendly), and when you are done, you free the entire pool at once

>They have been trying to prove they can achieve Arena-like benefits with, for example, improved GC algorithms, but all have failed to land

The new Green Tea GC from Go 1.25 [0]:

  Instead of scanning objects we scan whole pages. Instead of tracking objects on our work list, we track whole pages. We still need to mark objects at the end of the day, but we’ll track marked objects locally to each page, rather than across the whole heap.

Sounds like a similar direction: "let's work with many objects at once". They mention better cache-friendliness and all.

[0] https://go.dev/blog/greenteagc

Re: Golang's big miss on memory arenas

#58

Post by Yokohiii » Wed, Dec 10, 2025, 8:47 PM UTC

stlava wrote: post #14

At the end of the day there has to be a tradeoff between ease of use and performance. Having spent a lot of time optimizing high throughput services in go, it always felt like I was fighting the language. And that's because I was... sure they could add arenas but that just feels like what it is, a patch over the fact you're working alongside a GC.

It's more like fighting ideology. Each language goes long ways to teach their idiomatic ways, but if it comes to performance most languages break down at that point. Writing fast code makes you feel dirty, but the fault is in the constant signalling of DON'T DO THAT.

Re: Golang's big miss on memory arenas

#59

Post by 9rx » Wed, Dec 10, 2025, 9:11 PM UTC

pjmlp wrote: post #9

They could probably learn one or two things on how Java and .NET do arenas, just saying.

They did. That is how they learned arenas are the wrong abstraction and why the project is now looking at memory regions instead.

Re: Golang's big miss on memory arenas

#60

Post by Yokohiii » Wed, Dec 10, 2025, 9:12 PM UTC

I am a bit confused about the API pollution issue with arenas. I think it's a valid point to think about, but at the same time I don't think the average dev will do any extra steps for the faster thing to do.