I would like to see a reference to the place/proposal where Go team has actually rejected the idea of arenas. I have not see this ever in their issues.
Golang's big miss on memory arenas
31–40 of 157 posts
Re: Golang's big miss on memory arenas
#32The vibe I get from this post is of someone who hasn't routinely used arenas in the past and thinks they're kind of a big deal. But a huge part of the point of an arena is how simple it is. You can just build one. Meanwhile, the idea that arena handles were going to be threaded through every high-allocation path in the standard library is fanciful.
I'm curious, do you have any arena experience out of c/cpp/rust/zig? It may be that you can "just" build one, but you can't "just" use it and expect any of the available libraries and built ins to work with it. How many things would you have to "just" rewrite?
> How many things would you have to "just" rewrite?
The same ones you'd have to rewrite using the (experimental) arenas implementation found in the standard library. While not the only reason, this is the primary reason for why it was abandoned; it didn't really fit into the ecosystem the way users would expect — you included, apparently.
"Memory regions" is the successor, which is trying to tackle the concerns you have. Work on it is ongoing.
Re: Golang's big miss on memory arenas
#33Go now has memory regions, an automatic form of arenas: https://go.googlesource.com/proposal/+/refs/heads/master/des...
I think the deeper issue is that Go's garbage collector is just not performant enough. And at the same time, Go is massively parallel with a shared-everything memory model, so as heaps get bigger, the impact of the imperfect GC becomes more and more noticeable.
Java also had this issue, and they spent decades on tuning collectors. Azul even produced custom hardware for it, at one point in time. I don't think Go needs to go in that direction.
Re: Golang's big miss on memory arenas
#34The vibe I get from this post is of someone who hasn't routinely used arenas in the past and thinks they're kind of a big deal. But a huge part of the point of an arena is how simple it is. You can just build one. Meanwhile, the idea that arena handles were going to be threaded through every high-allocation path in the standard library is fanciful.
I'm curious, do you have any arena experience out of c/cpp/rust/zig? It may be that you can "just" build one, but you can't "just" use it and expect any of the available libraries and built ins to work with it. How many things would you have to "just" rewrite?
[deleted]
Re: Golang's big miss on memory arenas
#35I 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…
I am not sure I understand moving GC concern. Arena content would not be controlled by GC, otherwise it defeats the purpose of Arena.
A moving GC would make it simple to move any remaining live objects back under normal GC control once the arena goes out of scope.
You could probably also do it without moving actually, it just gets a little more complex.
Re: Golang's big miss on memory arenas
#36Earlier quoted context omitted.
I'm curious, do you have any arena experience out of c/cpp/rust/zig? It may be that you can "just" build one, but you can't "just" use it and expect any of the available libraries and built ins to work with it. How many things would you have to "just" rewrite?
> How many things would you have to "just" rewrite? The same ones you'd have to rewrite using the (experimental) arenas implementation found in the standard library. While not the only reason, this is the primary reason for why it was abandoned; it didn't really fit into the ecosystem the way users would expect — you included, apparently. "Memory regions" is the successor, which is trying to tackle the concerns you h…
Re: Golang's big miss on memory arenas
#37one question that always plagues me when we talk about mixing manual and automatic memory systems is...how does it work? if we have a mixed graph of automatic and manual objects, it seems like we dont have a choice except to have garbage collection enabled for everything and make a new root (call it the programmer) that keeps track of whether or not the object has been explicitly freed. since we still have the tracin…
I know there have been solutions in the Java world for >20 years, though I can't comment on well they work in practice.
From a quick search, _An Implementation of Scoped Memory for Real-Time Java_ (https://people.csail.mit.edu/rinard/paper/emsoft01.pdf) provides a decent overview:
> Real-Time Java extends this memory model to support two new kinds of memory: immortal memory and scoped memory. Objects allocated in immortal memory live for the entire execution of the program. The garbage collector scans objects allocated in immortal memory to find (and potentially change) references into the garbage collected heap but does not otherwise manipulate these objects.
> Each scoped memory conceptually contains a preallocated region of memory that threads can enter and exit. Once a thread enters a scoped memory, it can allocate objects out of that memory, with each allocation taking a predictable amount of time. When the thread exits the scoped memory, the implementation deallocates all objects allocated in the scoped memory without garbage collection. The specification supports nested entry and exit of scoped memories, which threads can use to obtain a stack of active scoped memories. The lifetimes of the objects stored in the inner scoped memories are contained in the lifetimes of the objects stored in the outer scoped memories. As for objects allocated in immortal memory, the garbage collector scans objects allocated in scoped memory to find (and potentially change) references into the garbage collected heap but does not otherwise manipulate these objects.
> The Real-Time Java specification uses dynamic access checks to prevent dangling references and ensure the safety of using scoped memories. If the program attempts to create either 1) a reference from an object allocated in the heap to an object allocated in a scoped memory or 2) a reference from an object allocated in an outer scoped memory to an object allocated in an inner scoped memory, the specification requires the implementation to throw an exception.
Re: Golang's big miss on memory arenas
#38I 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…
That sounds similar to the memory regions proposal[1], which is what came out of what was learned from tinkering with arenas. [1] https://github.com/golang/go/discussions/70257
Indeed, but then I wouldn't call it a "big miss" (the title of the article, which doesn't mention regions either).
Re: Golang's big miss on memory arenas
#39Earlier quoted context omitted.
I am not sure I understand moving GC concern. Arena content would not be controlled by GC, otherwise it defeats the purpose of Arena.
A moving GC would make it simple to move any remaining live objects back under normal GC control once the arena goes out of scope. You could probably also do it without moving actually, it just gets a little more complex.
I don't understand this, once Arena is gone, all contained objects will be destroyed altogether, that's the idea of Arena, no need to move them to GC control.
Re: Golang's big miss on memory arenas
#40Earlier quoted context omitted.
That sounds similar to the memory regions proposal[1], which is what came out of what was learned from tinkering with arenas. [1] https://github.com/golang/go/discussions/70257
Indeed, but then I wouldn't call it a "big miss" (the title of the article, which doesn't mention regions either).
[deleted]