I think we should rename FixedBufferAllocator to BumpAllocator.
The fact that FixedBufferAllocator operates on a fixed buffer is not descriptive enough. It is much more important that it is a bump allocator (to reuse memory you must deallocate in the reverse order of allocation).
There are other allocators that operate on fixed buffers, for example:
Thank you for reading my rant.
List of humans impacted by this:
āI agreeā is less than 10 characters so this forum software prevents me from simply posting those words. But, I agree!
As a non-native English speaker, the word ābumpā does not help me.
In software dev speak, so far the only other typical use Iāve seen was in commit messages like āBump YYZ to 1.2.3ā.
So, until now I thought it roughly means ānudgeā. And I knew ābumpersā from pinball machines.
I actually had to look for translations or synonyms.
And I found āpushā.
Ok, this makes sense, because in a way this allocator works like a stack with variable element size and in this context push/pop are well-known verbs.
I suggest to also consider StackAllocator or LIFOAllocator for the name.
If you search bump allocator you will get explanations and examples of how the allocation strategy in multiple languages, if you search fixed buffer allocator, I get a bunch of zig specific things. Meaning bump allocator is a much more well known term than fixed buffer allocator.
Thatās because itās often used to learn allocators, since itās a such a simple strategy, anyone who knows even a little about allocation will likely know what a bump allocator is.
That being said, in the context of zig ArenaAllocator is also a bump allocator, anyone who knows even a little will probably get confused about what the difference is, as bump allocation is mostly used for arenaās.
If we want better names, something like FixedArenaAllocator and or GrowableArenaAllocator, Bump and Arena are rather interchangeable.
Hmm, so Iām an exception to this rule.
Maybe Iām too old. Actually I never considered an allocator which doesnāt allow freeing elements in any order.
But maybe Iām not the only one for whom the option to actually choose from different allocators is new, and most people have never before implemented an allocator themselves, so this nomenclature shouldnāt be expected pre-knowledge for Zig users.
I donāt blame you for not knowing something you probably have never needed to even interact with before.
but
Implementing a fixed arena/bump allocator is quite common in c and similar languages.
Choosing an allocator isnāt new, itās just been made better and more often in recent years, especially with the new systems languages.
When most allocations were/still are done with libc malloc, changing the allocator was still a thing, libcās often provide the ability to use a custom implementation of malloc/free and different libcās default allocator is a big deal for performance itās one of the main comparisons that are made among libcās.
Granted, outside niche c uses and newer systems languages, the fact that allocation isnāt magic is not brought up or even useful information.
I have even heard of C programmers that donāt understand what malloc does even at a basic conceptual level.
Anyway, from looking at various Zig-related internet sites, it seems that even a lot of experienced Zig users seem to not know the restriction regarding the order of freeing and if you search the net, most pages just say āuse this if you know an upper bound for the memory in advance cause itās fastā.
So people seem to think it is basically a size-restricted , but still general purpose allocator (think of using -Xmx with Java), which it isnāt.
Probably the wording heap vs stack also adds to the confusion, because allocators are needed for storing data outside of the stack, in the heap. And āheapā has a fixed connotation of an unordered pile of data. But inside a FixedBufferAllocator, the data is stored in strict order of allocation, without gaps (except for alignment) and allocation/deallocation of elements only works LIFO.
FixedArenaAllocator is no better name in this regard.
I think one of the words Bump or Stack or LIFO should be part of the name.
I think Bump or Arena makes sense because they imply that you can allocate, free in reverse and reset everything.
With Stack or LIFO I wouldnāt expect to be able to reset the allocator.
And I think being able to reset is the much more important feature, because it is quite rare that you can reliably use free in reverse.
There is an entry in Region-based memory management - Wikipedia.
Memory allocators using region-based managements are often called area allocators, and when they work by only ābumpingā a single pointer, as bump allocators.
As a non-native English speaker, the word ābumpā does not help me.
IMHO sometimes itās better to go with the established name instead of more descriptive name. E.g. in sokol-gfx I went with āviewā instead of ābindingā for a new object type. āBindingā would better fit into the rest of the API, but āviewā has been the historically established term that everybody working with 3D APIs already knows.
ā¦also as another non-native speaker, I heard BumpAllocator often enough to know what it means. Same with āPoolAllocatorā, the mental picture of a swimming pool isnāt very useful there, but itās the established term 
PS: come to think of it, at least half of computing terms donāt make any intuitive sense to me, for instance Iāve always seen the keywords of a programming language as some sort of mnemonics / symbols / magic-runes instead of actual readable words. Thatās also why I think its pointless to ālocalizeā programming languages or computing terms (even though German computer scientists had come up with some pretty cool steam-punk-style creations, like āKellerspeicherā (ābasement storageā) for āstackā 
I am not familiar with the term āBumpā 
šAllocator
As an alternative to the name ābump allocatorā I could imagine ālinear allocatorā, that would be more descriptive.
BumpAllocator is ok as well, because if you donāt know this term, like me, youāll probably wonder why itās called this way and will search for the term.
Whereas FixedBufferAllocator and ArenaAllocator, for developers outside of the small group of allocator specialists, by their name say that the total size is limited (and the idea that the whole contents can be freed with just one call), but not that the ordering of free operations is restricted.
In fact I see the fact that one can free stack-wise as a nice bonus, which is useful in some special use-cases.
The docs say nothing about the restriction in āchoosing allocatorsā, and thus are actually quite misleading.
A bit OT, but personally, Iād like to see an allocator in the std lib (or is there, except when composing one yourself?) which allows to specify a min size and a max size and uses reasonable defaults to acquire more from the OS as needed, when current size < needed size < max size.
elaborate on this. Operating systems usually track memory in large chunks called, pages, you can only get a page at a time from the Os, the page size should and is expected to not change during your program, often it is completely static and compile time known.
A single page is larger than most allocations, depending on what youāre doing ofc. Usually 4kb, though 64kb is becoming more common.
I think that Fixed prefix is quite important because it marks that FBA operates with fixed-sized slice (memory is limited). So, as for me, FixedStackAllocator is good variant.
I get what you mean, though āstack allocatorā probably means someone could think @alloca has made a return 
The stdlib already has a growable bump allocator, (oops vulpesx already suggested FixedArenaAllocator)ArenaAllocator, which also frees individually only for the most recent allocation Maybe FixedArenaAllocator is thus a consistent alternative?
Though I like BumpAllocator too, the init function makes it clear itās fixed buffer.
I know all of that.
What I mean is, say, (depending on the program, of course), start with requesting 256 MB from the OS, and allow up to 512 MB. Inside these bounds, for example requesting additional memory from the OS could go in chunks of 1 MB (or 256 KB, you choose), instead of requesting 4KB pages repeatedly, wasting a very small percentage of memory for the benefit of fewer syscalls.
AFAIK the DebugAllocator already supports configuring a max size, but not a min size.