397275 - investigate timeout of objects in memory cache

Status: RESOLVED WONTFIX

(Core :: Networking: Cache, defect)

Description

[Jo Hermans]

Currently, the memory cache implements the LRU-SP algorithm. This means that when we're looking for candidates to be deleted (to make room), not a regular least-recently-used algorithm is used, but larger objects are selected first (still in LRU order ofcourse). That ensures that only very few large objects needs to be destroyed, instead of potentially dozens of small ones. The reason is that it's much slower to load 100 small objects of 10KB then 1 large 1MB object (due to the number of requests), even though the data size is the same. Clever.

If I'm looking in about:cache, I can see that there are many (hundreds) of small-size objects in the cache, like small images, favicons, webbugs and similar. But I recognize lots of objects that I have downloaded long ago, even hours ago. They shouldn't have been in the memory cache anymore, since their pages (and content viewers) have been gone a long time ago.

The reason that they're still around is that the LRU-SP algorithm has always found enough room in the cache by deleting a few large objects, and never needed to go down to the queue with the small objects. Those small objects will be deleted when you download a page that uses more than the maximum storage size (which ensures that all objects not in use will be deleted in an attempt to go back to the maximum size). Or when you open up a lot of tabs (which will lock objects in memory). Now that the trunk has fixed several bugs with docshell leaks, I always have a memory cache that is below the maximum size, often a lot below. And thus, I find more of these old images in the cache than in FF 2.0.

In the light of Roc's proposal for using time-based caching rather than traditional space-bounded caching <http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/3020179ad0f328df/d33ba841e506658e>, maybe it's a good idea to have a timer that scans the memory cache every few minutes, and removes images that not have been used for a while (an hour ?). There's already a mLastFetched field in nsCacheEntry that we can use for this, but mExpirationTime should not be used for this though. The timeout should probably be larger than the timeout for the bfcache from bug 395045.

I'm not proposing to remove the current algorithm, but just helping it a bit in certain scenarios where it might fail to remove some images. Note that most users will push old images much sooner out of the cache, especially when using lots of tabs and image-heavy websites.

Comment 1

[Jo Hermans]

Note that we can't delete an image that is in use (obviously), so this timer would not be able to remove 'locked' images, like the ones that result from a docshell leak. If you see old images in your memory cache, it's possible that they're caused by such a leak.

Comment 2

[Jo Hermans]

Adding the 'mlk' keyword, not because it's a real memory leak, but because we can have objects that are not removed from memory, because the eviction algorithm always manages to pick other (larger) ones. In that regard, they can be considered memory leaks, although the total amount of memory used in the cache stays the same.

If you have been surfing for hours, you might find hundreds of small images in your memory cache (even expired and very old ones). Just look at the 'Number of entries' counter in about:cache - it will increase. They might get kicked out when you encounter a page that needs more memory than available in the memory cache (like in bug 213391), but if you never load such a page, then some of them will stay in the cache forever.

Note that these images also used to carry a GDI object or pixmap with them, but bug 296818 is now used to remove them after 45 seconds.

Comment 3

[Jo Hermans]

Closing my own bug, as the memory cache is hardly used these days.