Lots of good stuff happened this week in MemShrink-land.
Necko Buffer Cache
I removed the Necko buffer cache. This cache used nsRecyclingAllocator to delay the freeing of up to 24 short-lived 32KB chunks (24 x 16KB on Mobile/B2G) in the hope that they could be reused soon. The cache would fill up very quickly and the chunks wouldn’t be freed unless zero re-allocations occurred for 15 minutes. This idea is to avoid malloc/free churn, but the re-allocations weren’t that frequent, and heap allocators like jemalloc tend to handle cases like this pretty well, so performance wasn’t affected noticeably. Removing the cache has the following additional benefits.
- nsRecyclingAllocator added a clownshoe-ish extra word to each chunk, which meant that the 32KB (or 16KB) allocations were being rounded up by jemalloc to 36KB (or 20KB), resulting in 96KB (24 x 4KB) of wasted memory.
- This cache wasn’t covered by memory reporters, so about:memory’s “heap-unclassified” number has dropped by 864KB (24 x 36KB) on desktop and 480KB (24 x 20KB) on mobile.
I also removed the one other use of nsRecyclingAllocator in libjar, for which this recycling behaviour also had no noticeable effect. This meant I could then remove nsRecyclingAllocator itself. Taras Glek summarized things nicely: “I’m happy to see placebos go away”.
Other Stuff
I gave a talk at the linux.conf.au Browser MiniConf entitled “Notes on Reducing Firefox’s Memory Consumption”, which got some attention on Slashdot.
Henrik Skupin reported that Ghostery 2.6.2 and 2.7beta2 have memory leaks (zombie compartments). I contacted the authors today and they said they are looking into the problem, so hopefully we’ll see a fix soon.
Gian-Carlo Pascutto reworked the code that downloads the safe browsing database to use less memory, and to have a fallback if memory runs out. This memory usage is transient and so the main benefit is that it prevents some out-of-memory crashes that were happening frequently.
Last week I mentioned bug 703427, which held up the possibility of a simple, big reduction in SQLite memory usage. Marco Bonardo did some analysis, and unfortunately the patch caused large increases in the number of disk accesses, and so it won’t work. A shame.
Kyle Huey fixed a zombie compartment that occurred when right-clicking on a single-line textbox. The fun thing about this was that in only 3 hours and 35 minutes, the following events happened: the bug report was filed, the problem was confirmed by two people, the bug report was re-categorized into the appropriate component, a patch was posted, the patch was reviewed, the patch landed on mozilla-central, and the bug report was marked as fixed! And approval for back-porting to Aurora was granted 8 hours later. Not bad. Kyle has also made progress on a more frequent zombie compartment caused by searching for text.
Jonathan Kew made the shaped-word caches (which are involved in text rendering) discard their data on memory pressure events.
Quote of the week
A commenter on my blog named jas said (the full comment is here):
a year ago, FF’s memory usage was about 10x what chrome was using in respect to the sites we were running…
so we have switched to chrome…
i just tested FF 9.0.1 against chrome, and it actually is running better than chrome in the memory department, which is good. but, it’s not good enough to make us switch back (running maybe 20% better in terms of memory). a tenfold difference would warrant a switch. in our instance, it was too little, too late.
but glad you are making improvements.
So that’s good, I guess?
I also like this comment from the aforementioned Slashdot thread!
Bug Counts
Here are the current bug counts.
- P1: 24 (-3/+1)
- P2: 131 (-8/+7)
- P3: 69 (-1/+3)
- Unprioritized: 3 (-3/+2)
That’s a net drop of two, largely because I went through and closed some P1 and P2 bugs that were stale or had been fixed elsewhere.
