It is well past due time to revisit memory allocation from first principles. I recently finished my PhD on the topic, and realized that we have yet to agree on a consistent definition of fragmentation (see Wilson et al's seminal survey on "Dynamic Storage Allocation"), much less how to deal with it.

When I was in the trenches, I had constant cognitive dissonance against the fact that (i) "it's a solved problem" and (ii) low-to-no-malloc was often presented as a feature of low-level code.

My take is, train a SOTA deep learning system on solved static memory allocation instances (which is NP-complete already) and build a dynamic malloc on top.

To see where the static SOTA was a couple years ago, see this: https://arxiv.org/abs/2504.04874

And also my general audience-friendly presentation of it: https://cappadokes.github.io/jekyll/update/2025/07/16/welcom...

Disclaimer: I've moved on past academia and I may have missed one or two breakthroughs. But the older the problem, the higher the probability of it staying open.

I'm not sure anybody has ever felt memory allocation was a solved problem. But more that it's a difficult one to do well for everybody.

You can build fancy balancing trees, heaps and all sorts to try and counteract fragmentation, but then you risk messing up cache coherency and you may spend a lot of time doing tedious busywork that can hold up real work.

What we have now is subobtimal for sure. Particularly if you come along and allocate huge swathes of memory in userland and then release it, only to re-alloc it. Huge page tables help a lot here, from the user/kernel side of things. But of course that is also not a perfect solution. Most apps don't want huge page tables as they don't map well onto normal things like browsing and listening to music. And so it goes; round and round.

I completely agree. In August I discovered the key to faster data transmission is better memory management. This allowed me to write a common protocol library in TypeScript that is about 35x faster than the current fastest implementation.

Due to a defect in my perf tool I eventually discovered that about 99.2% of processing time was spent on memory management, not instruction processing or network buffer. I was working in a high level garbage collected language, so I could not fine tune adjustments to pointers. Instead I got creative with call stack management and low level data frame header authoring. Now I am trying to replicate that success back to a low level http 1.1 implementation and it’s much more challenging.

I think I have a very simple fix that solves fragmentation. Force the size of every buffer and every array to be a power of two. What do you think?