21–30 of 49 posts
I vaguely remember when working with the DOS memory allocator many years ago, you could choose between the first/next/best/worst fit strategies, and best fit would tend to produce the worst fragmentation (creating lots of tiny fragments); but as others have noted, it highly depends on the allocation pattern of the application.
The blog post sadly doesn't cover what alternatives are out there, and why they settled on their choice. Besides tcmalloc, there are jmalloc, hoard, the more recent mimalloc, a bunch of commercial options, ... Would have been interesting to see a comparison. Edit: background is in this thread: https://news.ycombinator.com/item?id=26013230
Do you think any of these stand a chance at replacing Doug Lea's malloc in glibc, or does dlmalloc provide more desirable behavior for the general case?
Why don’t things like malloc get fixed? I’ve known about these issues for years. Does the core team not know?
We've spent endless hours trying to identify leaks before we finally tried a few alternative allocators. We switched to jemalloc and the positive effects where huge.
Its a bit weird that this is still an issue.
Earlier quoted context omitted.
Because there's no such thing as a truly general purpose memory allocator. Memory allocation is built to some purpose, and the programmer who uses it should be aware of its problems. There's probably a technical reason why the original glibc malloc does what it does (probably better optimized for low-thread counts)
What you say is technically true but can be used to just hand wave away any issue. Things can almost always be improved. Allocators like TCMalloc are not significantly worse in single threaded mode. The glibc allocator just isn’t very good. I have personally fought with the glibc allocator and seen issues with it that don’t exist on other OSes.
Obviously there are downsides to GC, but it's interesting to see how in this scenario malloc+free had the same "uses way more memory than strictly necessary" problem that people usually pin on garbage collectors.
Why don’t things like malloc get fixed? I’ve known about these issues for years. Does the core team not know?
Because there's no such thing as a truly general purpose memory allocator. Memory allocation is built to some purpose, and the programmer who uses it should be aware of its problems. There's probably a technical reason why the original glibc malloc does what it does (probably better optimized for low-thread counts)
If glibc malloc is so bad at something like this I find it hard to believe it would be great at anything important if jemalloc/tcmalloc are not.
This problem hit the Ruby community hard about 5 years ago. Basically everyone uses jemalloc or tcmalloc in production in the Ruby community nowadays. What frustrates me is the malloc community's sort of blase reaction along the lines of "there's no bug, this is expected behavior".
I wrote a commercial memory allocator (long long gone) for pre MacOS 10 and tested it by writing a ton of memory bashing applications based on every perverse pattern I could think of in order to ensure it was fast, failure free and limited fragmentation. Of course from that era I didn't need to support multiple threads so that made it somewhat easier, but in building it (and studying others at the time) it was obviou…
It's a quick watch at 1.5x speed, the last third is an interview.
I've spent some time really studying memory allocation. It seems to me that almost any high-performance application will take advantage of the fine-details of memory allocators to optimize themselves. There's something to be said about garbage collection as an actual strategy (!!). I know people think that garbage collection is slow, but... very smart people have put their minds on the memory problem. A generational…
(To my mind, "manual memory management" is when you get a big slab of memory from something, doesn't much matter what, and everything else is managed in your application code. If you're not doing that, you've got some sort of "automation" involved, and that automation can mismatch your program's memory needs every bit as much as a "GC" can.)