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.
gorjusborg · 3h ago
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?)
williamcotton · 3h ago
Another use case is a per-request arena for a web server.
nine_k · 15m ago
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.
- 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.
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?)