Mar 09

Gecko’s new image cache

Now that I’ve finally checked bug 466586 in to the mozilla-1.9.1/Firefox 3.5 development branch, I consider the design of Imagelib’s cache finished. I planned on blogging about this a while ago, but other problems distracted me.

When I joined the Mozilla Corporation’s gfx group in February of 2008, I was tasked with what seemed like a simple job: create a hashtable-based cache for imagelib, so it no longer had to use necko’s memory cache. (The work to implement this new cache was tracked in bug 430061.) While this seemed like unnecessary reimplementation, I was assured by Stuart and Vlad that necko’s memory cache was meant for an entirely different class of object, and that the large images stored in it were crowding out those objects (such as pages loaded over SSL).

Initially, this seemed like a simple job, but it turned out to be a multi-month effort that involved a lot of rewriting, debugging, collaboration, and patience. The last two attributes were especially embodied by Boris Zbarsky, who went out of his way to help me debug problems I didn’t understand, reviewed far too many iterations of patches, and was generally helpful in a way that I think exemplifies Mozilla’s community spirit. Thank you, Boris.

The most important fruit of all this labour is the reduction in memory use it made possible: a clever eviction policy lets us halve the size of the cache while maintaining the same real-world performance.

The remainder of this post will be a detailed explanation of the cache’s design, how it is implemented, and how I came to the decisions I made. I plan on rolling this into into an MDC article at some point, so if you have questions, please ask them.

Continue reading →

Feb 09

How you can help with recent image library changes on mozilla-central

Over the course of Mozilla’s 1.9.1 branch development, I’ve made a number of pretty important changes to Gecko/Firefox’s image library. I plan on blogging more about those changes in the future, but in a nutshell, instead of using necko’s memory cache to store decoded images, imagelib (libpr0n) now uses its own hash table, eviction criteria, and resurrection methods to cache decoded images.

As part of the changes for bug 466586, I’ve made it so that images that are still in use – for example, an image displayed in a webpage that you have open – are always accessible from the cache. Only once the image isn’t being used anymore do we start thinking about removing it from the cache (and freeing up its memory). Unfortunately, my current patch (available on the bug, and checked in to mozilla-central) has some latent bugs that I have never been able to reproduce. I do have proof that these bugs exist: in particular, several crashes have shown up when expiring images from the cache since I checked in the patch.

Currently, this code is only checked in to mozilla-central, i.e., the 1.9.2 or mozilla-central branch. I don’t have any test cases for these bugs (though I’m trying to get URLs for the crashes), but if you see a crash in your up-to-date Minefield build (2009-02-18 or newer) that contains “img” in the stack trace, or you get an abort in your debug build in imgCacheEntry, please file a bug with what you were doing, whether it’s reproducible, what URL you were at, and any other details you can find. (MDC has some good information about how to report and get information on crashes in Firefox.)

The bug this patch fixes is a Firefox 3.1 beta 3 blocker, so the more users this code has (and consequently the more eyes we have on it), the better.

UPDATE: Bug 480352 has been filed on this unknown crash, along with some bare-bones instructions on how you can help.