There are so many complaints here about how simplistic this is and how it is nowhere near what a "good" malloc does. That's kind of the point. Let's implement the most brain-dead version of this code. This is code you can quickly understand and reason about. It gives you a baseline to understand all the improvements that are included in a "real" malloc.
It would have been nice to include a list of the types of changes that a modern malloc would make to this basic structure to make it faster or fix bugs.
Maybe we could standardise on a set of adjectives to cover the spectrum from: "this is a handwave that needs filling in" and "this is cheap and cheerful code that does the basic thing" all the way to "this has been in production for a decade" and "this code not only handles 99,7% of the corner cases, it even also handles several dozen corner cases that only ever occurred on architectures which haven't existed since the 20th century"?
As someone who really enjoys reinventing the wheel for fun, the final words are something of a mantra for me:
> Let me stress here that while this collector is simple, it isn’t a toy.
> There are a ton of optimizations you can build on top of this—in GCs and programming languages, optimization is 90% of the effort—but the core code here is a legitimate real GC.
> It’s very similar to the collectors that were in Ruby and Lua until recently.
> You can ship production code that uses something exactly like this.
It would have been nice to include a list of the types of changes that a modern malloc would make to this basic structure to make it faster or fix bugs.