these malloc() and mfree() work on explicit memory regions! ... You could deallocate all its memory resources by just discarding the entire region you delegated to it.
This idea of a zone allocator keeps coming back. I've always wondered why it wasn't more popular in web servers, where it'd be natural to just bulk-free all memory after an HTTP request is done. I spent so much time tuning garbage collection in Java webapp servers and it was tempting to think it could all be trivialized.
Note that this article doesn’t make it very clear that dmr/malloc is the kernel allocator; I think all the others it discusses are userland allocators. (The early unix kernels had their source split between directories ken and dmr, a kind of charming instance of Conway’s law.)
I've always wondered why it wasn't more popular in web servers, where it'd be natural to just bulk-free all memory after an HTTP request is done.
Both Apache httpd and nginx work that way; it’s a common idiom in C network servers. (previously)
Pool allocators get a lot of their efficiency from type punning so they are hard to write in languages other than C. In C++ you have added friction from placement new, the need to explicitly bless the type of a fresh allocation, and keeping track of which objects have destructors that must be called. You can write homogeneous pool allocators in higher-level languages with an array per type (and they can be useful to control GC pressure in languages like Java) but then the per-request top level needs to know every type that might be allocated, and there are multiple pools to reset instead of just one.
nelson | 4 hours ago
This idea of a zone allocator keeps coming back. I've always wondered why it wasn't more popular in web servers, where it'd be natural to just bulk-free all memory after an HTTP request is done. I spent so much time tuning garbage collection in Java webapp servers and it was tempting to think it could all be trivialized.
fanf | 3 hours ago
Note that this article doesn’t make it very clear that dmr/malloc is the kernel allocator; I think all the others it discusses are userland allocators. (The early unix kernels had their source split between directories ken and dmr, a kind of charming instance of Conway’s law.)
(I’m mildly disappointed the article omitted the notoriously cursed Bourne shell allocator.)
Both Apache httpd and nginx work that way; it’s a common idiom in C network servers. (previously)
Pool allocators get a lot of their efficiency from type punning so they are hard to write in languages other than C. In C++ you have added friction from placement new, the need to explicitly bless the type of a fresh allocation, and keeping track of which objects have destructors that must be called. You can write homogeneous pool allocators in higher-level languages with an array per type (and they can be useful to control GC pressure in languages like Java) but then the per-request top level needs to know every type that might be allocated, and there are multiple pools to reset instead of just one.