Re: Memory fragmentation?
Daniel Brooks <[email protected]> Thu, 15 Nov 2007 09:29:05 -0500
| Newsgroups | gmane.comp.mozilla.performance |
|---|---|
| Message-ID | <[email protected]> |
(this turned into a treatise, but oh well) "Michael Vincent van Rantwijk, MultiZilla" <[email protected]> writes: > So what happen in current Mozilla builds when the 'lifetime' is over? > Will this memory be available for re-allocation? Will is be re-used, > or not? I guess not. I don't think that it works like this, but I > thought it was worth to give it a shot to learn/understand what is > going on right now. Applications request memory from the operating system in 4 kilobyte pages. Obviously we can bundle up a lot of small objects into a single page. When one of those objects is freed, the space it occupied does become available for the app to reuse, if it can find something that will fit. Because there's no way to move objects around in memory once they're allocated, the memory can become fragmented, which means that all of the unallocated memory exists only as small chunks strewn through out the allocated pages. When the memory is fragmented like this, there are a lot of places you can allocate small objects, but to create large objects you have to request more pages from the OS. In addition, we can't release a page back to the OS if there is anything still in it. As it turns out, this is a large part of why Firefox's memory usage doesn't go down much when you close a tab - we may have freed a lot of things, but because of fragmentation there is still at least some part of each page being used. Fragmentation is not unique to Firefox, all applications have to deal with it. Some applications are written in programming languages that make provisions for garbage collection. This not only automatically frees any memory not being used, but it also allows the application to move all of the objects in it's memory around, to elminate the fragmentation. This is basically like defragmenting a hard drive. Firefox is written mostly in C and C++ which doesn't make any allowances for GC, so defragmenting the memory this way would be a huge undertaking. One proposed solution would be to make Firefox create a new heap for each website the user visits, and to make sure any memory allocated for that webpage goes to the correct heap. This would mean that all of the objects needed to render a given webpage are all located next to each other in memory, which means that when the user leaves a page or closes a tab and Firefox frees the objects created by that page, a large block of memory is freed all at once, returning those memory pages to the OS. This is basically what people mean when they talk about sorting allocations by lifetime. We don't know the exact lifetimes of these objects in advance (because we don't know when the user will close the tab), but we know that they will be destroyed together. It's also hoped that this would not be has huge an undertaking as going to a full GC. Obviously any discussion of this is complicated by the bfcache, which keeps the last half-dozen or so pages in memory even after the user has navigated away from them, but in the end that's a fairly unimportant detail. db48x