People have dealt with the audience question. As for the “non-sequitur” comment, as someone who has read similar material for other allocators, I can attest that every paragraph was in exactly the order it needed to be to understand the allocator design pretty quickly. It was actually really well structured. Allocators are hard to understand, not least because there are so many synonyms for both “some quantity of contiguous memory” and “collections of various types of those”. This piece came armed with diagrams, code examples that expose what’s happening behind the scenes, and walkthroughs of typical allocator executions at a very appropriate level of detail: enough to appreciate why it might work quite well. It didn’t compare to other designs but it was a worthy contribution of knowledge on its own.

(Edit, oh look at that, previously bookmarked 7 years ago.)

+1 this basically matches how a typical guide to an allocator is structured. As such it assumes basic familiarity with how theses things work.

I think it’s for people who have been coding in user land for a long time, but never actually dug into how glib’s heap memory management works.

It’s a pretty dry topic, important though it is, and I appreciate sploitfun taking the time to give me a tour through it.

The audience would be the very few people who actually care about what's going on inside the guts of malloc().

So mostly people writing high performance code and wondering things like how does it perform in threaded code, whether there are optimizations for small allocations, etc. And also very valuable to the very, very few people who might think "I can do better" and contribute an improvement.

Documentation about the deep internals of stuff can be extremely valuable, but since very few people need it, it tends to be a very rare find.

> So mostly people writing high performance code

I would have assumed those people would be deliberately using another allocator with known/documented/guaranteed qualities instead of whatever ambient allocator was in play at the time.

That or avoid allocation as much as possible so that the choice of allocator effectively matters very little.

When would using optimizing for specifically glibc’s allocator be maximally beneficial?

Some people who care about high performance code end up writing their own allocator. If you want to do that, you are going to have to read about glibc’s implementation at some point. Understanding general purpose allocators and what tradeoffs they choose is essential if you are looking to make different choices. The same is true if you are trying to choose a different allocator. It surely helps to understand the code you’re benchmarking in order to hear what your benchmarks are telling you.

Based on the author’s name, I think the audience is likely exploit developers. If you’ve found a memory corruption vulnerability in a program written in C/C++, you’ll likely need to have fine control of the heap in order to achieve control of execution. For example, imagine you’ve found a heap overflow, meaning data is being written outside the bounds of an allocation into an adjacent allocation. In that case you’d need to understand where glibc places each allocation so that you can control which object gets overwritten.