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).
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.
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...
I am not sure I understand moving GC concern. Arena content would not be controlled by GC, otherwise it defeats the purpose of Arena.
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