[tpolzer]

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 but still safe otherwise).

[9rx]

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

[tpolzer]

Indeed, but then I wouldn't call it a "big miss" (the title of the article, which doesn't mention regions either).

[9rx]

I like to think this is our token AI-slop article for the day, but I'm not sure if even an LLM can hallucinate that much.

[dmpk2k]

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

[raggi]

Sure, you drop an active arena pointer into TLS and allocate out of that then pop and free it once you pop the stack. Producing API guarantees that all incoming references are dead before you do that though, that's the real trick.

[riku_iki]

I am not sure I understand moving GC concern. Arena content would not be controlled by GC, otherwise it defeats the purpose of Arena.

[tpolzer]

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.

[riku_iki]

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.