4 ms·

> performance - which is basically the main reason to use an Arena I'd argue the main reason Zig/C programmers use arenas is for correctness, not performance.

> performance - which is basically the main reason to use an Arena I'd argue the main reason Zig/C programmers use arenas is for correctness, not performance. You might think of arenas as a performance thing if you consider the alternative to be a GC, but the alternative in Zig/C is usually to do things manually.

chaz72 2mo ago
Regardless of focusing on correctness or performance, it looks to me like the author didn’t understand arenas that well. Like the other commenter said, “You use an arena when you have computation that might consume a bunch of scratch memory, and then you want to free all of that memory at once when the computation is done.” That’s the entire point of arenas.
- Mikhail_Edoshin 2mo ago
  That would be the quality of any allocator that is created as a separate object. Internally it can use any algorithm, e.g. a typical malloc-free cycle. Once you're done, you drop the whole allocator, it returns big blocks it used internally to the system (or even to the parent allocator), so the memory is freed in wholesale manner. "Arena" normally also implies the allocation algorithm is stack-like, but this is not a hard requirement tied to the implementation.
  - simiones 2mo ago
    An arena is a type of allocator that allocates efficiently and never deallocates (`arena.free(ptr)` is a no-op). That is basically what defines it. Since there is no free(), doing allocation via a simple pointer bump is the most natural implementation.
    - Mikhail_Edoshin 2mo ago
      The usage of the term varies. E.g. the GNU C library uses the word "arena" to describe the internal structures used by its 'malloc' allocator. What you describe they call "obstack", which also has internal "arenas". So at least here the word "arena" means a list of pages used internally by a single allocator regardless of its operational principle. In any case the quality that allows to quickly free all tied memory is not exclusive to a bump-type allocator; any allocator that exists on its own can do that. It is just that we do not often see standalone malloc-like allocators. But they are totally possible. A bump allocator supports other actions that are indeed exclusive to its design: partial free (set a mark and later "return" to it and free everything that was allocated after that mark) or allocating the last chunk step-by-step ("growing"). These are indeed unique to bump allocator, but the way it frees all memory is not. For example, one might want to combine a bump and slab allocator: generally bump, but allow for 'free' for small sizes with subsequent reuse of the freed slab. This would be a tad slower than pure bump, but will have a better use of memory in certain scenarios.

chaz72 2mo ago

Regardless of focusing on correctness or performance, it looks to me like the author didn’t understand arenas that well. Like the other commenter said, “You use an arena when you have computation that might consume a bunch of scratch memory, and then you want to free all of that memory at once when the computation is done.” That’s the entire point of arenas.

Mikhail_Edoshin 2mo ago
That would be the quality of any allocator that is created as a separate object. Internally it can use any algorithm, e.g. a typical malloc-free cycle. Once you're done, you drop the whole allocator, it returns big blocks it used internally to the system (or even to the parent allocator), so the memory is freed in wholesale manner. "Arena" normally also implies the allocation algorithm is stack-like, but this is not a hard requirement tied to the implementation.
- simiones 2mo ago
  An arena is a type of allocator that allocates efficiently and never deallocates (`arena.free(ptr)` is a no-op). That is basically what defines it. Since there is no free(), doing allocation via a simple pointer bump is the most natural implementation.
  - Mikhail_Edoshin 2mo ago
    The usage of the term varies. E.g. the GNU C library uses the word "arena" to describe the internal structures used by its 'malloc' allocator. What you describe they call "obstack", which also has internal "arenas". So at least here the word "arena" means a list of pages used internally by a single allocator regardless of its operational principle. In any case the quality that allows to quickly free all tied memory is not exclusive to a bump-type allocator; any allocator that exists on its own can do that. It is just that we do not often see standalone malloc-like allocators. But they are totally possible. A bump allocator supports other actions that are indeed exclusive to its design: partial free (set a mark and later "return" to it and free everything that was allocated after that mark) or allocating the last chunk step-by-step ("growing"). These are indeed unique to bump allocator, but the way it frees all memory is not. For example, one might want to combine a bump and slab allocator: generally bump, but allow for 'free' for small sizes with subsequent reuse of the freed slab. This would be a tad slower than pure bump, but will have a better use of memory in certain scenarios.