Understand the Temporary Allocator; Understand arenas
12 points by Aks
12 points by Aks
What’s the idea behind reallocating player actions every frame? Couldn’t you draw the UI just by reading g_mem.inventory.items without an auxiliary array?
Question about allocator terminology: all arena allocators I’ve seen typically allocate a static amount of memory? Would one that allocates dynamically also be called an arena allocators as well?
there are growable arenas. they usually use a linked list of chunks, or an array of arrays, rather than reallocating. because if you’re using an arena, you probably want stable pointer addresses
i’m making one that reserves a static range of address space up front, and commits pages as needed
Yeah I implemented a dynamic allocator-thing built with a linked list for a project, but I am not really sure if it correct to call it an arena allocator, so I ended up calling it a memory region. But would you call it a growable arena then?
Basically arena allocators are more about scoping lifetime, and it just happens that this can often be used to improve performance.
The intended semantic here is close to objective-c’s autorelease pools, you can allocate your objects, and functions can return allocated temporary objects, and you don’t need to manually track ownership or the need to release objects. I can’t recall whether the odin version of this allows called functions to use the active temporary allocator, but that’s generally something that most arena allocators are assumed to allow.
Anyway, the issue I have with the temporary allocator here is that there is nothing to stop you returning a pointer from inside a given temp allocator scope, and there is no way to force the lifetime to extend if you find that you need to.
It seems like whenever I see a motivating example for an arena allocator, it’s either a game or a parser of some kind.
A web request handler would be an excellent place for an arena allocator, and AFAIK a lot of web servers work exactly like that. Apache for example:
If the memory is needed for the lifetime of a single request, it is allocated from a pool called request pool. (See: ap_create_request in protocol.c for request pool creation)
https://medium.com/brundas-tech-notes/apr-memory-pools-5f462c4f67cb
Its also worked well for a fuse based filesystem I’ve been building, they also follow a similar request<->respond pattern.
I’d be interested to see how programming a web/app server using arena allocation would be. There’s a clear lifetime for almost everything in a request.
printing/serialization, too. though usually just for a big string buffer
you can frame a lot of problems as parsing, though
You could imagine serving a network request. For each request we can allocate an arena. Any memory that does not need to live after the network request is complete can be allocated out of this arena, and we can free the arena in order to reuse the memory (in practice we’d probably have a pool of arenas in order to avoid excess trips to the allocator).
You’d have to be careful with large/complex requests, though, or you could balloon memory usage. None of the allocated memory can be reused until the request finishes. For example, maybe you’re streaming a very large response from a db query — if every iteration of your per-row loop allocates memory, like for a temporary buffer, you could end up consuming memory proportional to the response size.
Yeah that’s absolutely a concern and games and parsers do run into similar issues. Arenas are at their best when your memory usage is pretty simple. If they’re more complicated, you’re liable to get runaway memory usage.