The main news in the past two weeks has been about Kyle Huey’s patch that prevents most chrome-to-content leaks, which are the most common kind of add-on leak.\u00a0 Testing showed it worked beautifully, but caused a knock-on leak in add-ons built with old versions (1.3 and earlier) of the Add-on SDK<\/a>.\u00a0 (This<\/a> received<\/a> a<\/a> lot<\/a> of<\/a> attention<\/a>.)\u00a0 Kyle then made a slight tweak<\/a> that fixed that knock-on leak<\/a>.\u00a0 So we’re currently still on track for Firefox 15 being “the one that fixes add-on leaks”.<\/p>\n For completeness, here are the add-ons that we know were temporarily affected by that knock-on leak:\u00a0 Wallflower<\/a>, Visual Hashing<\/a>, Translate This!<\/a>, Easy YouTube Video Downloader<\/a>.\u00a0 They (and probably quite a few others) are all working fine again now.<\/p>\n Here’s a quote from an email that one user sent to Kyle this week.<\/p>\n Firefox was leaking about 1.5GB per hour for me. It started with Firefox 3. I tracked it down to Ghostery and NoScript, but even without those addons it leaked about 500MB per hour of browsing.<\/p>\n GC and CC times got up into the 10 second range. Ugly. Really really ugly! And this is on top of the line massively overclocked hardware, too. I had to install a new addon to add a restart button to Firefox, because Firefox froze solid after hitting 2GB of memory usage. I also patched it after every update to allow up to 4GB, buying a little more time…<\/p>\n Then your patch comes along and solves it all… you are awesome man – totally awesome!<\/p><\/blockquote>\n Another user — one who uses the leaky Autopager add-on<\/a> — commented<\/a> on Kyle’s blog.<\/p>\n Certainly, before this fix I would find that Firefox often became sluggish (input lag, slow paint operations, less than silky smooth scroll animations) as the memory usage built up. It’s hard to say how much various factors contributed to the whole, but GC pauses did undoubtedly cause the scroll animation stuttering.<\/p>\n Restarting was the cure. I haven’t noticed the same symptoms since, and while I haven’t had enough chance to make a conclusive judgement, the signs certainly seem to be good.<\/p>\n I have a full tab strip more often than not, and Fx set to load tabs from last time. This is offset by the wonderful and elegantly simple tabs on demand feature. I’m running a 2 year old laptop with 4GB ram.<\/p><\/blockquote>\n And while we’re on the topic, here’s a comment<\/a> from my blog.<\/p>\n Opened my firefox today, 30+ Tabs (only counting the ones in the active group, the others aren’t loaded), using just little more than 330 MB of RAM. A year ago, with Firefox 4, this would have been impossible. Keep it going!<\/p><\/blockquote>\n Good times.<\/p>\n The following add-ons had zombie compartments fixed:\u00a0 Youtube Ratings Preview<\/a>, SPDY Indicator<\/a>\u00a0 It’s likely these leaks would have been fixed by Kyle’s change, but since Firefox 15 won’t be released until August 28, it’s good that they’ve been fixed now.\u00a0 (Indeed, the AMO review policy still requires that add-ons not cause zombie compartments with the current release of Firefox;\u00a0 that policy may be revisited once Firefox 15 is released.)<\/p>\n The other big news is that compartment-per-global<\/a> (CPG) landed, thanks to the work of various people, especially Luke Wagner and Bobby Holley.\u00a0 Bobby explained what this means and explored some of the consequences<\/a>.<\/p>\n CPG will allow lots of things within Firefox to become simpler and faster.\u00a0 The main disadvantage is, unfortunately, increased memory consumption, as can be seen on areweslimyet.com<\/a>.\u00a0 (Thanks to Luke, this increase was less than it could have been<\/a>.)\u00a0 This is mostly due to more fragmentation in the JavaScript heap — we now have many more compartments, and each 4KB heap arena cannot be shared between compartments, so there are many more partially empty arenas present.<\/p>\n You might think this would make me bang my head against the wall in frustration, but it doesn’t.\u00a0 That’s because even if I ignore the many non-MemShrink-related benefits of CPG, there are two big MemShrink-related ones.<\/p>\n First, CPG will enable per-tab memory reporting<\/a>, something that users have been requesting for years.<\/p>\n Second, CPG will lead to much more detail in about:memory and about:compartments.\u00a0 For example, Nils Maier has written a patch<\/a> that makes it obvious all the JavaScript modules that have been loaded<\/a>.\u00a0 Another example:\u00a0 Justin Dolske found that plusone.google.com was doing something silly (constantly creating new iframes?) that caused huge numbers of compartments to be created<\/a>;\u00a0 without CPG I think all those globals would have been lumped into a single compartment and the problem would have been much less obvious.\u00a0 More information in about:memory will lead to more diagnosis of existing problems — particularly leaks of various kinds — in both Firefox and websites.<\/p>\n Kevin Locke tweaked the JS memory reporters so that more compartments are distinguished, instead of being lumped together<\/a>.\u00a0 This was his first Mozilla patch — well done, Kevin!<\/p>\n Nathan Froyd improved the coverage of the layout memory reporters<\/a>.\u00a0 This significantly reduces “heap-unclassified” for huge pages like the single-page version of the HTML5 spec<\/a>.<\/p>\n Here are the current bug counts.<\/p>\n Mostly bouncing around at the moment.<\/p>\n","protected":false},"excerpt":{"rendered":" Add-ons The main news in the past two weeks has been about Kyle Huey’s patch that prevents most chrome-to-content leaks, which are the most common kind of add-on leak.\u00a0 Testing showed it worked beautifully, but caused a knock-on leak in add-ons built with old versions (1.3 and earlier) of the Add-on SDK.\u00a0 (This received a […]<\/p>\n","protected":false},"author":139,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[119,30,4544,4546],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts\/1936"}],"collection":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/users\/139"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/comments?post=1936"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts\/1936\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/media?parent=1936"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/categories?post=1936"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/tags?post=1936"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Compartment-per-global<\/h3>\n
Memory Reporting<\/h3>\n
Bug counts<\/h3>\n
\n