Implicit context [1] was one of the coolest features of a programming language I’ve ever seen that no one has ever implemented. And I’m really not sure why. Not just Go but most languages have this context passing problem with varying degrees of solution quality, making this implicit and built in could have opened up so many possibilities, more than just arenas. [1]: https://youtu.be/ciGQCP6HgqI
Clojure has had dynamic vars since the beginning (2007?). Johnathan probably got it from elisp though.
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…
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.
Implicit context [1] was one of the coolest features of a programming language I’ve ever seen that no one has ever implemented. And I’m really not sure why. Not just Go but most languages have this context passing problem with varying degrees of solution quality, making this implicit and built in could have opened up so many possibilities, more than just arenas. [1]: https://youtu.be/ciGQCP6HgqI
Doesn't Scala have this? It sounds like a good idea to me too, but I haven't had a chance to try it for real myself and I've heard other people say it's a bad thing.
But maybe it's like exceptions, where people get involved with a project originally written by people who misused all sorts of language constructs and came away thinking the language was awful, or don't learn idiomatic usage or something.
You totally can build it using unsafe and generics. I’ve done it with mmap-backed byte slices for arbitrary object storage.
With a number of caveats. You cannot reimplement arenas as the experiment did without special hooks into the runtime. https://github.com/golang/go/blob/master/src/arena/arena.go
The special hooks for context and arena (actually arena(s) can be part of context) should have eliminated the need to change signatures for threading context and arena handles through the chain of calls. Instead there should have been an API (both - internal and user accessible) to check and pick, if present, the closest one on stack (somewhat similar to how you can get ClassLoader and the hierarchy of them in Java)
Man this person is mediocre at best. You can do fully manual memory management in Go if you want. The runtime is full of tons of examples where they have 0-alloc, Pools, ring buffers, Assembly, and tons of other tricks. If you really want an arena like behavior you could allocate a byte slice and use unsafe to cast it to literally any type. But like… the write up completely missed that manual memory management exists…
This isn't true in practice because you won't be able to control where allocations are made in the dependencies you use, including inside the Go standard library itself. You could rewrite/fork that code, but then you lose access to the Go ecosystem. The big miss of the OP is that it ignores the Go region proposal, which is using lessons learned from this project to solve the issue in a more tractable way. So while Ar…
I had to fork go’s CSV to make it re-use buffers and avoid defensive copies. But im not sure an arena api is a panacea here - even if i can supply an arena, the library needs certain guarantees about how memory it returns is aliased / used by the caller. Maybe it would still defensive copy into the arena, maybe not. So i don’t see how taking arena as parameter lets a function reason about how safely it can use the arena.
Man this person is mediocre at best. You can do fully manual memory management in Go if you want. The runtime is full of tons of examples where they have 0-alloc, Pools, ring buffers, Assembly, and tons of other tricks. If you really want an arena like behavior you could allocate a byte slice and use unsafe to cast it to literally any type. But like… the write up completely missed that manual memory management exists…
I personally loved using Go 8 years ago. When I built a proof of concept for a new project in both Go and Rust, it became clear that Rust would provide the semantics I’m looking for out of the box. Less fighting with the garbage collector or rolling out my own memory management solution. If I’m doing that with a lot of ugly code - I might as well use idiomatic Zig with arenas. This is exactly the point the author tri…
> Or a third option can be to write your hot loops in one such language; and continue using Go for everything else. Problem solved.
Or use Go and write ugly code for those hot loops instead of introducing another language and build system. Then you can still enjoy nicety of GC in other parts of your code.
My understanding is that that arena allows you to allocate memory segments, but you can't do much with it, you can't allocate var or object on it like in C++ for example, so its almost useless.
You certainly can, as they were designed as JNI replacement, with the goal to fully support the C ABI of the host platform.
You can either do the whole boilerplate manually with Panama set of APIs, or write a C header file and let jextract do the work of boilerplate generation.
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…
> Yes: I used arenas a lot when I was shipping C code; they're a very easy way to get big speed boosts out of code that does a lot of malloc This is something I look forwards to exploring later in my current pet project, right now it has possibly the stupidest GC (just tracks C++ 'new' allocated objects) but is set up for drop in arena allocation with placement new so, we'll see how much that matters later on. There…
C++ has the ability to override new and delete, and the standard library supports allocators as type parameters exactly because the standard implementation purpose is to be good enough.
There are plenty of specialisations that get more performance out, e.g. multi-threaded code in NUMA architectures.