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.
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.
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.)
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.
Not sure if the author is here, but I recommend the author install LangaugeTool in their browser, or whichever editor they use - the amount of mistakes makes it a bit confusing to read.
>I recommend the author install LangaugeTool in their browser
Touche.
I get the impression that the author isn't a native speaker. And as you yourself demonstrate, these things are hard for the best of us.
Ultimately though they're presumably proficient at the intricacies of malloc rather than writing, and have taken the time to share what they've learnt. Better writing will hopefully come with practice
Out of curiosity, I went to the page of the tool and input the comment contents, which correctly caught the mistake, although tools typically miss various compound names in my experience, due to their dictionaries being limited: https://languagetool.org/
For example, I proofread my own blog posts by using the built in LibreOffice spellcheck (offline dictionary) and that has actually been useful in catching a typo or two in most of my writing. Personally, I probably wouldn't use a browser plugin due to concerns over data privacy and not caring much beyond the browser's built in spellcheck, but I personally support the overall spellchecking suggestion, as long as the tone is positive!
For some folks, the style and punctation suggestions in some of the tools out there might also be useful.
Dear english speakers, this author learned your language, took the time to understand glibc malloc, and then wrote an article in your language as best they could explaining it, at no cost to you.
17 comments
[ 0.26 ms ] story [ 49.4 ms ] threadI feel like every paragraph is a non-sequitur.
It’s a pretty dry topic, important though it is, and I appreciate sploitfun taking the time to give me a tour through it.
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.
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?
(Edit, oh look at that, previously bookmarked 7 years ago.)
Touche.
I get the impression that the author isn't a native speaker. And as you yourself demonstrate, these things are hard for the best of us.
Ultimately though they're presumably proficient at the intricacies of malloc rather than writing, and have taken the time to share what they've learnt. Better writing will hopefully come with practice
Out of curiosity, I went to the page of the tool and input the comment contents, which correctly caught the mistake, although tools typically miss various compound names in my experience, due to their dictionaries being limited: https://languagetool.org/
For example, I proofread my own blog posts by using the built in LibreOffice spellcheck (offline dictionary) and that has actually been useful in catching a typo or two in most of my writing. Personally, I probably wouldn't use a browser plugin due to concerns over data privacy and not caring much beyond the browser's built in spellcheck, but I personally support the overall spellchecking suggestion, as long as the tone is positive!
For some folks, the style and punctation suggestions in some of the tools out there might also be useful.
You can't invalidate my experience by just saying "works for me", though that would be nice and easy.
Don't nitpick about grammar, please.