You're just describing every allocator in the world, except many (most?) skip the zeroing part.
libc already does that. What is it that yours is adding?
I'd say 25 years ago you could write your own naive allocator, make just a couple of assumptions for your use case, and beat libc. But no more.
One of the selling points of Java in the 90s was the compacting part. Because in the 90s fragmentation was a much bigger problem than it is today. Today the libc allocators have advanced by maybe tens of thousands of PhDs worth of theory and practice. Oh, and we have 64bit virtual address space, which helps with some (but not all) of the problems with memory fragmentation.
> Today the libc allocators have advanced by maybe tens of thousands of PhDs worth of theory and practice.
Have they, though? Looking at the blame on glibc's malloc.c, the most substantial change in the last 10 years has been the addition of memory tagging. Apart from that, I mainly just see a bunch of small tweaks to the tcache, fastbins, etc., and the basic logic is broadly the same as it was 20 years ago. Similarly, the MallocInternals wiki page [0] appears mostly as it did in 2016, except for some more explanations of the tcache added in 2018.
I can easily believe that lots of work has been done on malloc/free-style allocators, but from what I've seen of most libc allocators, they hardly stand at the forefront of this work. (Except for the ones that just vendor some standalone allocator library and keep it up to date. But that describes neither Windows nor Linux.)
And of course, if you're writing your own allocator, you can relax some of the constraints, e.g., you can drop most of the multithreading support and not have to fool around with locks and shared arenas and whatnot.
> Today the libc allocators have advanced by maybe tens of thousands of PhDs worth of theory and practice.
For fun I wrote up a very basic memory manager and benchmarked it against free/malloc. On my Mac (M3) the manager was 3x faster. On a random kubernetes pod (alpine) it was 33x faster. Performance increases as memory size goes up.
Well, not on MacOS, I imagine (you tell me which repository/mailing list they should send a PR to :p). Really Windows and MacOS seem like the places where a malloc replacement is generally quite useful (Windows is a particularly big offender in this regard, Windows malloc is abysmal - MacOS less so iirc but still pretty bad) - it's glibc that's somewhat of an outlier by being generally pretty good.
libc already does that. What is it that yours is adding?
I'd say 25 years ago you could write your own naive allocator, make just a couple of assumptions for your use case, and beat libc. But no more.
One of the selling points of Java in the 90s was the compacting part. Because in the 90s fragmentation was a much bigger problem than it is today. Today the libc allocators have advanced by maybe tens of thousands of PhDs worth of theory and practice. Oh, and we have 64bit virtual address space, which helps with some (but not all) of the problems with memory fragmentation.
See this post from Ian Lance Taylor about why Go didn't even bother with a compacting GC: https://groups.google.com/g/golang-nuts/c/KJiyv2mV2pU?pli=1