We had our first MemShrink meeting a week ago. Here’s some progress that’s been made since then. Please note that this is a list of things that caught my eye, and isn’t meant to be exhaustive in any way.
Two big improvements were made to garbage collection trigger heuristics.
- Gregor Wagner added a time-based trigger to the garbage collector. Most notably, this should prevent slow build-ups of garbage when the browser is left idle but an open website is doing a small amount of continual work (eg. updates on a news site). We’ve had a lot of reports about this problem, so this will hopefully be a big win. Thanks, Gregor! Note that if the browser is truly idle it won’t trigger, so it shouldn’t cause power problems with Firefox mobile. See this comment for full details of the new trigger.
- Luke Wagner (no relation to Gregor!) fixed a gap in the garbage collector’s allocation-based triggers — certain string allocations weren’t being counted by the garbage collector, which meant it allowed them to build up excessively. This fix particularly helps with complex regular expression operations.
Two improvements were made to the coverage of about:memory, thus reducing the amount of memory falling into the “heap-unclassified” bucket.
- I added three new memory reporters: explicit/js/scripts, explicit/js/object-slots, explicit/js/string-chars. When I open Gmail, these three together account for 11% of the explicit allocations.
- Kyle Huey added a new memory reporter called xpti-working-set, which measures memory used by the XPCOM typelib system. This is usually a bit over 1MB of memory.
Justin Lebar made progress on measuring page fault counts and using them to respond when memory pressure is high.
Finally, I made progress on reducing unnecessary compartment overhead, which I described previously.
8 replies on “MemShrink progress, week 1”
Ah…hope this good work gets into FF asap…World is moving fast..!
Just wanted to say thank god you guys are finally tackling this.
P.S another usage case where Firefox consumes large amounts of memory is browsing any jpg heavy sites for long periods (without closing the browser), just go look at high res images on Interfacelift.com for an hour or two and watch it’s memory usage soar. This also slows down Firefox causing it to stutter.
http://interfacelift.com/wallpaper/downloads/date/any/
Other web browsers don’t have these problems only Firefox.
Rex: see https://bugzilla.mozilla.org/show_bug.cgi?id=660577 and its dependent bugs. Some progress is being made; decompressed images in background tabs are currently held onto for 2–4 minutes before being discarded, it’s likely that’ll be reduced to 10–20 seconds soon. Then there’s some longer-term work that needs to be done to improve things further.
You are a relentless! kudos
Another memory based slow down is the management
of animated gifs. The site http://psc.apl.washington.edu/zhang/IDAO/seasonal_outlook.html gives a view of arctic ice dynamics.
In about a minute it “eats” 500 MB. On a (low end)
mac-air it freezes firefox and renders the dock
unresponsive for about 30 seconds.
It seems to keep the full decoded gif in memory,
rather than discarding older frames.
augustm: that sounds similar to https://bugzilla.mozilla.org/show_bug.cgi?id=629606, which is about animated PNGs.
Perhaps, but it is not the scrolling/reloading that
gives the problem- memory climbs at about
3MB/s just on loading the page. (I keep
the mac Activity_Monitor open to watch).
Firefox5, but I see the same in 3.6 and 6.
It isn’t a leak, since it drops a minute or
so after closing the tab, but it is aggressively
taking memory while the animations are running.
I understand that this is the sort of thing that
you are looking at.
Perhaps this is the bug
https://bugzilla.mozilla.org/show_bug.cgi?id=523950
Nicholas there are so few heroes in this world but you are one of them.
It is such a relief to see candid, honest admissions in bugzilla, from a lot of key players, that memory consumption was indeed broken in Fx 4 and that this is an unacceptable situation.
For once I do not feel the need to jump into a debate or discussion on a bug (only to be told my comments are not appropriate for bugzilla) which is great since I’ve been locked out of the system anyway!