I don't see this as very well conceived article, since the two concepts being discussed, manual memory management, and arena allocators are really orthogonal.
Arena allocators aren't going to save you from memory management bugs, and aren't intended to. They are just an efficient may to allocate and free a bunch of chunks of memory that have the same lifetime, for example due to belonging to the same data structure. The idea is that you just sequentially allocate from a large chunk of memory, then free up the entire large chunk in one go at the end of the collective lifetime of the allocated pieces.
The things that make memory management in C error-prone are that:
1) C doesn't have objects/destructors, so all freeing of memory is manual, thereby creating the possibility that you mess it up.
2) C's pointers don't have ownership semantics, and therefore also doesn't have niceties like shared ownership (cf C++'s shared vs unique pointers). All ownership tracking is manual, giving you another chance to mess up.
The only think that is going to save you from memory management errors in C is programmer discipline and attention to detail.
It seems like the choice of a stacklike Arena API makes the examples a little more confusing than needed. An arena doesn't necessarily mean allocation 2 must be freed before allocation 1.
If this seems cool to you, check out Zig. The libraries use a similar convention where code that might allocate requires passing an allocator, which may be an arena, or something cool we don't even know about yet.
The author's defense of C reminds me of this classic youtube video: https://www.youtube.com/watch?v=443UNeGrFoM&pp=ygUPaG93IGkgc...
I am sure the video above will cause immediate disagreement (I think it goes too far on some topics), but I urge people to consider the ideas contained within.
(I seem to have mis-posted this to another thread?)
Ryan is one of the people who really badly want arenas to be a borrow checker substitute, but they're not. You still need to make sure references to objects in the arena don't outlive the arena itself.
Another use case is a per-request arena for a web server.
This article is quite long, and spends many kilobytes to make the following points (AFAICT):
- Pure malloc/free allocation is error-prone and expensive; it's too granular in many cases.
- Stack allocation has obvious limitations due to its LIFO nature. RAII has similar limitations.
- Let's use a bunch o separate, independent allocators / memory arenas instead. We can free them more quickly in one go when needed. We can group objects by lifetime using them. Having thread-local arenas naturally separates thread-local allocations from program-global allocations.
This sounds pretty reasonable, and, AFAIK, Zig leans heavily on this concept. I wonder if Rust can reap some of the benefits of arena-based allocation by leveraging its lifetime tracking.