So every time memory is allocated on the heap in C/C++ the allocator is called. In C malloc is a function that the allocator provides. In C++ new uses malloc unless you use a placement new (more on that later). This allocator has to get memory from the OS and in Linux it uses mmap or sbrk. The allocator normally wants to get more memory then is being asked so it can create a pool of memory and not have to ask for more all the time because that is slow. This also means the allocator can get memory fragmentation. Jemalloc is suspose the be very good at keeping fragmentation down and that is why firefox uses it. The other thing about memory allocator because they like a pool that don't let go of memory. the free fuction or delete just puts the memory back in the pool.
Jemalloc does a much better job of giving back memory to the OS then the standard allocator in glibc. So if you have an app that uses a lot of memory and then frees it all and you want to get the memory back try jemalloc. I hack the code out of firefox and it work great. Just two file there somewhere and you have to compile with some macros defined. Or you could just get it from the guy who made it. When I did it he had yet to release that. Once you install that all you have to do is link you execuable to it when you compile. Because glibc uses weak symbols for the alloctor funcation the malloc and free and other from the jemalloc implentation will over ride the built in. This is cool I think.
There are lots of other alloctors out there you google and find a lot them google itself made one. Some have a lot of stuff built in to track memory usage like the google one. It also never returns memory unless you call some nonstanderd function in a new version of the library. I forget the name of it I found it some comment I wish I had the link to. Just look at a .h file.
Anyway if the glibc malloc every lets you down it is easy to change and lots of chooses based one what you need. Give it a spin.
1 comment:
Good read. Memory allocation is no easy thing to program for, so it's nice that there are dozens of people and organizations out there that made their own versions, each with various strengths and weaknesses.
The allocator that comes with glibc is decent for general purposes, but doesn't have many of the features that you mentioned. It doesn't do too well at memory fragmentation prevention/reduction, doesn't have true "giving memory back to the OS", and isn't considered the fastest either. It is mighty fine though, despite all that.
So just remember, before you (that is, anyone reading this) go applying the latest/greatest memory allocator for a real project, ask yourself:
Is my project not meeting the performance/memory objectives?
If it isn't, then go ahead and attach a profiler to it and find the bottleneck. If it turns out that you need more speed, and you're spending the most time waiting on memory allocation (probably not likely though) then go for a speedy allocator. If your project runs for possibly hours at a time and seems like the memory keeps climbing, go for one that returns memory like jemalloc. I guess. I don't know. I mean, I've never used any other allocator but the default, and I also haven't profiled a C/C++ project yet. Not to mention I haven't encountered those problems yet. Maybe I should listen to my own advice, instead of dishing it out, no?
On a slightly different note, Sun's HotSpot Java VM is wicked fast with it's allocations, and also cleans out its consumed memory from time to time. But, if the code is already in C/C++ and you're contemplating using a different memory allocator, you could probably care less at that point in the project. :)
Post a Comment