New technical endeavors often push the limits of the state of the art. Discovering working solutions is important, but just as important are the transcendental travails that start with non-working attempted solutions.

28 November 2007

Firefox fragmentation?

As Firefox 3 nears release, some of its developers are taking a close look at memory fragmentation issues. There is good information over at pavlov.net that I won't repeat here. One recurring theme though is that memory usage in version 2 was reported by some users to be problematic, and fragmentation is a suspected culprit. This has motivated an investigation of memory fragmentation before version 3 is released.

As the author of jemalloc, I have a deep (read: obsessive) interest in memory fragmentation issues, so I spent some time brushing off my malloc plotting tools today. Here is a plot from a run of firefox 2.0.0.9 running on FreeBSD-current. In order to generate the allocation trace, I launched firefox, then went through several cycles of opening lots of tabs/windows and then closing most of them.Time starts at the left, and execution ends at the right. Each vertical column of pixels represents a snapshot of memory usage at a particular moment during program execution (time is measured by allocation events). Since there are millions of allocation events, most snapshots are left out to make the plot size manageable. Similarly, there are many bytes of memory that must be represented by each vertical column of pixels, so each pixel represents a bucket of 256kB. Low addresses are at the bottom of the plot.

Note the peaks that are mostly green. Those occur during peak memory usage periods, and overall, the plot shows that fragmentation isn't bad. Take this with a grain of salt though, since the plot only represents perhaps 15 minutes of heavy web browsing.

If you want to see much more detail (each bucket is 4kB -- one page), take a look at this image. It is big enough to cause most image viewers to choke, so beware.