Untangling Lifetimes: The Arena Allocator
rfleury.com
Untangling Lifetimes: The Arena Allocator
1–10 of 94 posts
Re: Untangling Lifetimes: The Arena Allocator
#2It is telling about the mean knowledge level of C in the vicinity of the author that first paragraph does not include «why subject yourself to a language with such a pervasive UB?»
Re: Untangling Lifetimes: The Arena Allocator
#3Anyone read it all and can tldr any interesting insights?
Re: Untangling Lifetimes: The Arena Allocator
#4Anyone read it all and can tldr any interesting insights?
This came up before. TL;DR: If you use arena allocators everywhere then you won't have any memory errors!
I think the idea is a really interesting one but it would be better if he didn't wrap it in typical "I don't make mistakes" hubris. I mean I guess at least this time he has some more reason than "because I'm not stupid" but I think he's still wrong.
His technique probably reduces the chance of memory errors, but there's still nothing checking his work so he's still going to make mistakes.
The other issue he doesn't address is resource allocation. It's fine to just drop the memory of a lot of things but sometimes you have to close files, handles, etc. RAII handles that perfectly. I'm not sure about this.
I would say RAII and Rust's borrow checker are still superior but it's definitely true that they don't work well with arenas.
Re: Untangling Lifetimes: The Arena Allocator
#5Anyone read it all and can tldr any interesting insights?
I am not a C programmer but I will try!
Malloc/free - can turn into a tangled mess as you need to keep symmetry, and apps might have complex dep. graphs
Stack - wonderfully simple but often if you need to share things across the depths of your program you need to define variables in shallower parts - but you won’t know how much is needed ahead of time. Example a parsing library.
Arena - like a single malloc / free with it’s own stack. Use this to allocate memory for objects that can be all freed at the same time (if they need to be freed at all). No need to malloc for each object.
Re: Untangling Lifetimes: The Arena Allocator
#6Anyone read it all and can tldr any interesting insights?
This came up before. TL;DR: If you use arena allocators everywhere then you won't have any memory errors! I think the idea is a really interesting one but it would be better if he didn't wrap it in typical "I don't make mistakes" hubris. I mean I guess at least this time he has some more reason than "because I'm not stupid" but I think he's still wrong. His technique probably reduces the chance of memory errors, but…
> I would say RAII and Rust's borrow checker are still superior but it's definitely true that they don't work well with arenas.
Note that this will definitely improve in future versions of Rust. Local allocators are an unstable feature already, and can support arena allocation.
Re: Untangling Lifetimes: The Arena Allocator
#7The author should take another look at RIIA.
The first big difference is that it works with non-memory resources too, for example open/close for files.
The second is that it makes heap allocated data feel a lot like stack allocated data, since the resources are ultimately owned by variables on the stack. With “move semantics” resources can be passed as arguments and returned by functions too, so the example of lifetimes crossing calls is fine. A function could take in a File, read some data, use that to select and open a different File, then return the new file and close the old file at the end of the call, and it would all be straightforward.
This is all present in C++. If it seems like an interesting idea to learn more about, I recommend trying it in Rust. It is the default, so there’s minimal syntax for it and all the standard library uses it.
Re: Untangling Lifetimes: The Arena Allocator
#8Anyone read it all and can tldr any interesting insights?
This came up before. TL;DR: If you use arena allocators everywhere then you won't have any memory errors! I think the idea is a really interesting one but it would be better if he didn't wrap it in typical "I don't make mistakes" hubris. I mean I guess at least this time he has some more reason than "because I'm not stupid" but I think he's still wrong. His technique probably reduces the chance of memory errors, but…
> RAII handles that perfectly. I'm not sure about this.
If you're asking whether arena allocators can handle resource cleanup, then I think the answer is yes. One way to do it is to embed an intrusive linked list of destructors into your arena. So, to push an object onto the arena you would:
1. Push a function pointer (the object's destructor) and the current destructor list head onto the arena.
2. Update the destructor list head to point to the top of the arena.
3. Push the object's data onto the arena, as usual.
(source: https://www.ea.com/frostbite/news/scope-stack-allocation)
Re: Untangling Lifetimes: The Arena Allocator
#9Anyone read it all and can tldr any interesting insights?
It's a good technical explanation of how arena allocation (a useful and easily googleable memory management technique) works in practice, in C, along with:
* A lot of arguing that all other ways of dealing with the problem (garbage collectors, RAII, etc) are misguided and make for worse programs. This is a lot more controversial than "arena allocation is useful" but I have some sympathy for it. He's not alone in thinking it. See the "Handmade Network" which this guy is associated with.
* A brief and unnecessary bit of free market fundamentalist politics, which seems par for the course for him.
* A general implication that he came up with this stuff himself, which he didn't. Arena allocation (under that name) dates back to the sixties.
Re: Untangling Lifetimes: The Arena Allocator
#10Is there an equivalent insight but instead of C it is web dev and instead of Malloc it is JQuery and GC being React? In other words is there an elegant way to build a complex SPA with vanilla JS