Leaky add-ons are a big problem, but there’s been lots of action relating to them recently.\u00a0 What follows is a summary of the situation and a request for help from currently Nightly testers who use add-ons.<\/p>\n
Kyle Huey’s patch<\/a> to prevent Chrome-to-Content leaks<\/a> landed recently.\u00a0 In theory it would prevent almost all add-ons zombie compartments, which constitute the majority of leaks from add-ons.\u00a0 And in practice, it appears to be working splendidly.<\/p>\n I did<\/a> some<\/a> testing<\/a> of eight add-ons that are known to leak: McAfee SiteAdvisor 3.4.1<\/a>(the old version that leaked every content compartment), Firebug 1.9.1<\/a>, PicPasso 1.0.1<\/a>, LoL 1.5<\/a>, YouTube Ratings Preview 1.03<\/a>, Enter Selects 7<\/a>, HttpFox 0.8.10<\/a>, and Link Resolve 0.7<\/a>.\u00a0 I tested with a “before” browser build that lacked Kyle’s patch, and an “after” browser build that had it.\u00a0 For every one of the tested add-ons, I could reproduce the zombie compartment(s) with the “before” build, but could not<\/em> reproduce any zombie compartment(s) with the “after” build.\u00a0 In other words, the patch worked perfectly.<\/p>\n To understand how important this is, consider this comment<\/a> on Kyle’s blog describing the effect of the patch.<\/p>\n I seem to be seeing really significant improvements from this. Normally Fx would start at 170MB and by the end of the day that would often be creeping up to 800 or 900 MB. Today using latest nightly I again started at 170, but now at the end of the day I’m only at 230MB!<\/p><\/blockquote>\n That’s a 4x reduction<\/strong> in memory consumption.<\/p>\n What effect does this have?\u00a0 The obvious benefit of reduced memory consumption<\/a> is that there will be less potential for paging.\u00a0 For example, if the above user is on a low-end machine without much RAM, a reduction in memory consumption from 800+MB to 230MB might greatly reduce paging, which would make Firefox much faster.<\/p>\n However, what if the user has a high-end machine with 16GB of RAM?\u00a0 Then paging isn’t an issue.\u00a0 But this improvement will still be a big deal on such a machine.\u00a0 This is because garbage collection and cycle collection cause pauses, and the length of the pauses are roughly proportional to the amount of live heap memory.\u00a0 (Incremental garbage collection will soon be enabled, which will result in smaller garbage collection pauses, but there are no plans for incremental cycle collection and so cycle collection pauses will still be relevant.)\u00a0 So even on high-end machines with lots of RAM, leaks can greatly hurt browser performance.\u00a0 In other words, add-on leaks are a Snappy<\/a> issue just as much as they are a MemShrink<\/a> issue.<\/p>\n [Update: Kyle found a simple way to fix this problem<\/a> with the Add-on SDK.]<\/strong><\/p>\n So Kyle’s patch is great, but the cutting of the chrome-to-content references was unlikely to be totally free of side-effects.\u00a0 And sure enough, last week Josh Matthews noticed that Dietrich Ayala’s Wallflower add-on was causing many zombie compartments<\/a>.\u00a0 Hmm, wasn’t Kyle’s patch supposed to stop exactly that?\u00a0 Well, it was expected to stop the most common cases, but there are some other leaks that could still cause zombie compartments.<\/p>\n The weird thing with this leak is that Wallflower is a really simple add-on.\u00a0 It’s built with the Add-on SDK and is only a few lines of code<\/a>.\u00a0 It turns out that Kyle’s patch caused the Add-on SDK to leak badly<\/a>.\u00a0 The exact reason is complex;\u00a0 you can see Kyle’s explanation here<\/a>.<\/p>\n This sounds really bad.\u00a0 Lots of add-ons are built with the Add-on SDK.\u00a0 Have we just exchanged one class of add-on leaks for another?\u00a0 I don’t believe so, for two reasons.<\/p>\n Still, the situation is far from ideal, because lots of add-ons are still built with older SDK versions.\u00a0 So, what to do?\u00a0 There’s a bug open discussing this question<\/a>, but it’s gotten bogged down due to differing opinions on what to do.\u00a0 Version 1.6.1 happened to fix all leaks in the Add-on SDK that were known prior to this problem, so we should be encouraging add-on authors to rebuild with it anyway.<\/p>\n In the meantime, if you use Nightly builds and use add-ons, please monitor about:compartments<\/a> and file bugs if you find that any add-ons are causing zombie compartments<\/strong>.\u00a0 If Wallflower is representative, the leaks will be very bad and so shouldn’t be hard to spot.\u00a0 Firefox 15 is scheduled for release on August 28th;\u00a0 we need as many affected add-ons to be rebuilt with the latest SDK before that date to minimize potential problems.<\/p>\n Another cause of high memory consumption in add-ons is FUEL.\u00a0 I know very little about it other than it’s also part of the Add-on SDK<\/span> sort of a proto-version of the Add-on SDK.\u00a0 The details are here<\/a> and here<\/a>.\u00a0 This is causing bad performance in Readability<\/a> and probably other add-ons.\u00a0 Something to be aware of.<\/p>\n","protected":false},"excerpt":{"rendered":" Leaky add-ons are a big problem, but there’s been lots of action relating to them recently.\u00a0 What follows is a summary of the situation and a request for help from currently Nightly testers who use add-ons. Two Steps Forward Kyle Huey’s patch to prevent Chrome-to-Content leaks landed recently.\u00a0 In theory it would prevent almost all […]<\/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\/1908"}],"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=1908"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts\/1908\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/media?parent=1908"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/categories?post=1908"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/tags?post=1908"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}One Step Back<\/h3>\n
\n
Problems with FUEL<\/h3>\n