Cool read! I have been getting my toes wet with the idea of explicit allocators in Zig. I haven't done anything with Odin yet, but it's cool to see that explicit allocators with off-the-shelf standard library implementations is making it's way into more languages.

I like composable single feature allocators, a free list is just another kind of allocator that may be plugged in at any point.

https://github.com/codr7/hacktical-c/tree/main/malloc1

https://github.com/codr7/hacktical-c/tree/main/malloc2

> You can only deallocate everything in the arena, not individual parts of it.

Untrue; this excludes the middle. GNU Obstack is a widely-used arena allocator with a "free everything allocated after this point" operation, among others.

This is arguing about the definition of an Arena.

It’s like if I say a stack only has push and pop, and you tell me you can search though and find another element.

It's really not. The multi-chunk arena it describes at the end of the article is exactly the same structure as GNU obstack, except that obstack also bothers to implement the free-to-mark operation.

It's trivial to provide the operation for any arena, finite (just set the end pointer to the given value) or chained (a little more work since you have to free chunks until the former succeeds). The operation is O(1) if you're within the last chunk or two (and if you're tuning your chunk size well, you usually will be), O(log n) if your chunks increase in size as you go, or O(n) if all your chunks are the same size (not necessarily a bad idea for some use cases), where n is the number of chunks you're freeing (much smaller than the number of bump allocations).

It'll depend on the allocator. Generally speaking, the better an allocator is at minimizing fragmentation, the slower it's going to be with new allocations.

That's why bump allocators are wicked fast, but make the trade-off the article mentions.

PostScript does something similar with its save and restore operators.