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.
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.
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?)
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.
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?)
Another use case is a per-request arena for a web server.
If PHP did one thing right, it is this: allocate resources while handling a request, free them all unconditionally when the response has been sent.