{"id":1067,"date":"2011-07-20T17:19:47","date_gmt":"2011-07-20T06:19:47","guid":{"rendered":"http:\/\/blog.mozilla.org\/nnethercote\/?p=1067"},"modified":"2011-07-20T17:19:47","modified_gmt":"2011-07-20T06:19:47","slug":"memshrink-progress-week-5","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/nnethercote\/2011\/07\/20\/memshrink-progress-week-5\/","title":{"rendered":"MemShrink progress, week 5"},"content":{"rendered":"<p>There were four main areas of MemShrink progress this week.<\/p>\n<h3>Killing zombie compartments<\/h3>\n<p>A<a href=\"http:\/\/blog.mozilla.org\/nnethercote\/2011\/07\/20\/zombie-compartments-recognize-and-report-them-stop-the-screaming\/\"> zombie compartment<\/a> is one that outlives its tab.\u00a0 Kyle Huey fixed a very common <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=671053\">class of short-lived zombie compartments caused by XmlHttpRequests<\/a>.\u00a0 These zombie compartments only lived for a couple of minutes, but this is an important fix because it makes makes memory usage follow tab usage better, and also makes detecting longer-lived zombie compartments much easier.<\/p>\n<p>Alon Zakai has also been doing heroic work tracking down <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=669545\">a zombie compartment related to web workers<\/a> exhibited at <a href=\"http:\/\/coffeekup.org\/\">coffeekup.org<\/a>.\u00a0 I&#8217;m sure he&#8217;d appreciate additional help from anyone who might be able to provide it.<\/p>\n<h3>Improving about:memory<\/h3>\n<p>Lots of progress here.<\/p>\n<ul>\n<li>I changed the per-compartment memory reporters so that multiple system compartments with the same name are reported separately, instead of being merged.\u00a0 This made it obvious that <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=672443\">JetPack-based add-ons can have dozens of system compartments<\/a>.\u00a0 I don&#8217;t know if anybody realized this previously, and it&#8217;s something of a concern.\u00a0 The compartments are currently distinguished in about:memory only by their address, as the following example shows.\u00a0 <a href=\"http:\/\/blog.mozilla.org\/nnethercote\/files\/2011\/07\/system-principal.png\"><img decoding=\"async\" loading=\"lazy\" title=\"system-principal\" src=\"http:\/\/blog.mozilla.org\/nnethercote\/files\/2011\/07\/system-principal.png\" alt=\"system principal including its address\" width=\"720\" height=\"36\" \/><\/a><br \/>\nIt would be great to add some identifying information that indicates what part of the code is responsible for creating each system compartment.\u00a0 That might even give us some much-needed per-add-on accounting.<\/li>\n<li>Andrew McCreight added a <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=665995\">memory reporter for the cycle collector<\/a>.<\/li>\n<li>I added a <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=669117\">memory reporter for the Necko (network) memory cache<\/a>.<\/li>\n<li>Justin Lebar fixed a <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=664659\">problem with the image memory reporters<\/a>, but it bounced due to a possible Tp5 RSS\/PrivateBytes regression on Mac.\u00a0 This was surprising, maybe it was just noise?<\/li>\n<li>I changed about:memory so that if there are multiple memory reporters with the same name, you can tell they were merged into a single entry.\u00a0 For example, in the following screenshot you can easily tell that there were four separate connections to the places database.<br \/>\n<a href=\"http:\/\/blog.mozilla.org\/nnethercote\/files\/2011\/07\/places.png\"><img decoding=\"async\" loading=\"lazy\" class=\"alignnone\" title=\"places\" src=\"http:\/\/blog.mozilla.org\/nnethercote\/files\/2011\/07\/places.png\" alt=\"places entry indicating duplication\" width=\"511\" height=\"74\" \/><\/a><\/li>\n<\/ul>\n<h3>Acting on memory pressure<\/h3>\n<p>Justin Lebar made some great progress on <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=670967\">triggering memory pressure events when physical or virtual memory is low on Windows<\/a>.\u00a0 See comments 28 and 29 on that bug for some nice graphs showing how this kept Firefox responsive when browsing some very image-intensive sites.\u00a0 This kind of adaptive behaviour is really important for getting Firefox to behave well on the full range of supported devices, from smartphones all the way up to desktop machines with lots of RAM.\u00a0 Go Justin!<\/p>\n<h3>Tweaking MemShrink processes<\/h3>\n<p>The <a href=\"https:\/\/wiki.mozilla.org\/Performance\/MemShrink\">MemShrink wiki page<\/a> used to be vague about the project&#8217;s goals.\u00a0 So this week I made it more precise.<\/p>\n<blockquote><p>[The] goal is to get the number of MemShrink P1 bugs down to zero. That will mean that all the bad leaks will have been fixed, and also the important auxiliary work (e.g. infrastructure to detect regressions) will be in place.<\/p><\/blockquote>\n<p>As a result, Jeff Muizelaar changed <a href=\"http:\/\/areweslimyet.com\/\">areweslimyet.com<\/a> to point to the list of open MemShrink P1 bugs.\u00a0 It previously pointed to a Tp5 Talos graph.<\/p>\n<p>On a related noted, we have six open meta-bugs for tracking leaks against Firefox releases, one for tracking non-leak memory use reductions, and one for improving memory-related tools.\u00a0 (These are listed on <a href=\"https:\/\/wiki.mozilla.org\/Performance\/MemShrink#Tracking_Current_Leaks\">the wiki<\/a>.)\u00a0 I <a href=\"http:\/\/blog.mozilla.org\/nnethercote\/2011\/05\/25\/a-new-way-of-tracking-leak-reports\/\">created<\/a> these bugs before MemShrink meetings started.\u00a0 But now that we are using the MemShrink whiteboard annotations assiduously, these tracking bugs don&#8217;t seem necessary &#8212; having two tracking mechanisms is overkill.\u00a0 In particular, I think their dependencies aren&#8217;t being updated consistently.\u00a0 So I propose to stop using them and close them.\u00a0 If you have any objections, please let me know and I&#8217;ll reconsider.\u00a0 If I do close them, I&#8217;ll make sure that all bugs blocking them have a MemShrink annotation so they won&#8217;t fall through the cracks.<\/p>\n<p>And that segues nicely into the MemShrink bug count for this week:<\/p>\n<ul>\n<li>P1: 26 (+2)<\/li>\n<li>P2: 49 (+0)<\/li>\n<li>P3: 33 (+4)<\/li>\n<li>Unprioritized: 6 (+4)<\/li>\n<\/ul>\n<p>Like last week, this increase mostly reflects the fact that people are coming up with new ideas for improvements.<\/p>\n<p>Finally, thanks to Jesse Ruderman for taking <a href=\"https:\/\/wiki.mozilla.org\/Performance\/MemShrink\/Meetings\/2011-07-19\">minutes<\/a> at this week&#8217;s meeting (and the <a href=\"https:\/\/wiki.mozilla.org\/Performance\/MemShrink\/Meetings\/2011-07-12\">previous<\/a> <a href=\"https:\/\/wiki.mozilla.org\/Performance\/MemShrink\/Meetings\/2011-07-05\">two<\/a>).<\/p>\n","protected":false},"excerpt":{"rendered":"<p>There were four main areas of MemShrink progress this week. Killing zombie compartments A zombie compartment is one that outlives its tab.\u00a0 Kyle Huey fixed a very common class of short-lived zombie compartments caused by XmlHttpRequests.\u00a0 These zombie compartments only lived for a couple of minutes, but this is an important fix because it makes [&hellip;]<\/p>\n","protected":false},"author":139,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4550,4554,30,4544,4546],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts\/1067"}],"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=1067"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts\/1067\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/media?parent=1067"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/categories?post=1067"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/tags?post=1067"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}