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