It’s been a busy couple of weeks for MemShrink.
B2G Memory Reporting
about:memory is our main tool for understanding memory consumption. On desktop Firefox it works very well. On Firefox mobile it works less well, partly because it’s hard to read all that text on a small screen, and partly because you can’t cut and paste, which makes bug reporting difficult. And on B2G (a.k.a. Firefox OS) it currently doesn’t work at all.
To remedy this, I implemented the ability to import and export memory reporter data in JSON format, and Justin Lebar sped up the exporting of this data and implemented a signal-based mechanism for triggering it. The idea is that developers can trigger an export of the data from their device and then view it in about:memory in desktop Firefox.
This will allow detailed memory profiling for B2G, which I have listed as #3 on the current MemShrink “big ticket items” list. The timing is good, because B2G has reached feature-freeze and so focus will now move to its performance and memory consumption as part of “Operation Slim Fast“.
(On a related note, Kartikaya Gupta and other engineers have started looking closely at the memory consumption of Firefox mobile on low-end devices.)
Generic Memory Reporting
I added memory reporting to IonMonkey. Happily, it appears to use very little memory, especially compared with JaegerMonkey. This is partly because it generates smaller code than JaegerMonkey, but mostly it’s because IonMonkey is only used to compile the small fraction of code that has been executed many 1000s of times. In comparison, JaegerMonkey is used to compile the much larger fraction of code that has been executed more than a few times.
Kyle Huey added memory reporters for attribute nodes and attribute maps, which improves the coverage of the memory reporting for the DOM.
Kyle Huey optimized the representation of repeated inline style rules. This means that for pages with many elements of the form
<foo style="blah">, the repeated
style="blah" part is now shared between the elements. This is a huge win on certain large, auto-generated pages. For example, on one page that holds a gigantic Mercurial diff, this change reduced 64-bit Firefox’s memory consumption from 1,759 MiB to 1,306 MiB.
Kyle Huey and Olli Pettay fixed a leak relating to web workers.
Seth Fowler made nsConsoleService only post a LogMessageRunnable to the event queue if there are any observers for it. This can save a lot of memory for pages that contains many errors.
Bad Graphics Drivers
An ongoing problem we have is that badly-written graphics drivers can cause outlandish (e.g. multi-GB) memory consumption. Here’s one example that was fixed by blocklisting one particular AMD driver. (That driver was also causing lots of crashes.)
It’s got to the point that if someone is seeing excessive memory consumption with no apparent explanation — e.g. immediately after start-up, with few tabs open — I’ll suggest they set layers.acceleration.disabled to true in about:config and there’s a good chance it’ll fix the problem. (Restarting in safe mode also disables hardware acceleration.) I don’t have any good ideas on how to improve this situation.
Here are the current bug counts.
- P1: 16 (-8/+3)
- P2: 97 (-2/+10)
- P3: 97 (-6/+3)
- Unprioritized: 3 (-3/+3)
In today’s MemShrink meeting we closed and downgraded a number of P1 bugs that (a) have been partially addressed, or (b) are less important than they first seemed, or (c) are duplicates.