{"id":1980,"date":"2012-06-13T16:06:40","date_gmt":"2012-06-13T05:06:40","guid":{"rendered":"http:\/\/blog.mozilla.org\/nnethercote\/?p=1980"},"modified":"2012-06-14T10:07:06","modified_gmt":"2012-06-13T23:07:06","slug":"memshrink-progress-week-51-52","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/nnethercote\/2012\/06\/13\/memshrink-progress-week-51-52\/","title":{"rendered":"MemShrink progress, week 51-52"},"content":{"rendered":"<h3>Memory Reporting<\/h3>\n<p>Nathan Froyd added much more detail to the <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=760831\">DOM<\/a> and <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=674922\">layout<\/a> memory reporters, as the following example shows.<\/p>\n<pre>\u251c\u2500\u25003,268,944 B (03.76%) -- window(http:\/\/www.reddit.com\/)\r\n\u2502\u00a0 \u251c\u2500\u25001,419,280 B (01.63%) -- layout\r\n\u2502\u00a0 \u2502\u00a0 \u251c\u2500\u2500\u2500\u2500403,904 B (00.46%) \u2500\u2500 style-sets\r\n\u2502\u00a0 \u2502\u00a0 \u251c\u2500\u2500\u2500\u2500285,856 B (00.33%) -- frames\r\n\u2502\u00a0 \u2502\u00a0 \u2502\u00a0\u00a0\u00a0 \u251c\u2500\u2500\u250090,000 B (00.10%) \u2500\u2500 nsInlineFrame\r\n\u2502\u00a0 \u2502\u00a0 \u2502\u00a0\u00a0\u00a0 \u251c\u2500\u2500\u250072,656 B (00.08%) \u2500\u2500 nsBlockFrame\r\n\u2502\u00a0 \u2502\u00a0 \u2502\u00a0\u00a0\u00a0 \u251c\u2500\u2500\u250062,496 B (00.07%) \u2500\u2500 nsTextFrame\r\n\u2502\u00a0 \u2502\u00a0 \u2502\u00a0\u00a0\u00a0 \u251c\u2500\u2500\u250042,672 B (00.05%) \u2500\u2500 nsHTMLScrollFrame\r\n\u2502\u00a0 \u2502\u00a0 \u2502\u00a0\u00a0\u00a0 \u2514\u2500\u2500\u250018,032 B (00.02%) \u2500\u2500 sundries\r\n\u2502\u00a0 \u2502\u00a0 \u251c\u2500\u2500\u2500\u2500259,392 B (00.30%) \u2500\u2500 pres-shell\r\n\u2502\u00a0 \u2502\u00a0 \u251c\u2500\u2500\u2500\u2500168,480 B (00.19%) \u2500\u2500 style-contexts\r\n\u2502\u00a0 \u2502\u00a0 \u251c\u2500\u2500\u2500\u2500160,176 B (00.18%) \u2500\u2500 pres-contexts\r\n\u2502\u00a0 \u2502\u00a0 \u251c\u2500\u2500\u2500\u2500\u250055,424 B (00.06%) \u2500\u2500 text-runs\r\n\u2502\u00a0 \u2502\u00a0 \u251c\u2500\u2500\u2500\u2500\u250045,792 B (00.05%) \u2500\u2500 rule-nodes\r\n\u2502\u00a0 \u2502\u00a0 \u2514\u2500\u2500\u2500\u2500\u250040,256 B (00.05%) \u2500\u2500 line-boxes\r\n\u2502\u00a0 \u251c\u2500\u2500\u2500\u2500986,240 B (01.13%) -- dom\r\n\u2502\u00a0 \u2502\u00a0\u00a0\u00a0 \u251c\u2500\u2500780,056 B (00.90%) \u2500\u2500 element-nodes\r\n\u2502\u00a0 \u2502\u00a0\u00a0\u00a0 \u251c\u2500\u2500156,184 B (00.18%) \u2500\u2500 text-nodes\r\n\u2502\u00a0 \u2502\u00a0\u00a0\u00a0 \u251c\u2500\u2500\u250039,936 B (00.05%) \u2500\u2500 other [2]\r\n\u2502\u00a0 \u2502\u00a0\u00a0\u00a0 \u2514\u2500\u2500\u250010,064 B (00.01%) \u2500\u2500 comment-nodes\r\n\u2502\u00a0 \u2514\u2500\u2500\u2500\u2500863,424 B (00.99%) \u2500\u2500 style-sheets<\/pre>\n<p>Although these changes slightly improved the coverage of the reporters (i.e. they reduce &#8220;heap-unclassified&#8221; a bit), the more important effect is that they give greater insight into DOM and layout memory consumption.\u00a0 [Update:\u00a0 Nathan <a href=\"http:\/\/blog.mozilla.org\/nfroyd\/2012\/06\/12\/aboutmemory-statistics-improvements\/\">blogged about these changes<\/a>.]<\/p>\n<p>I modified the memory reporter infrastructure and about:memory to <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=760352\">allow trees of measurements to be shown in the &#8220;Other Measurements&#8221; section of about:memory<\/a>.\u00a0 The following excerpt shows two sets of measurements that were previously shown in a flat list.<\/p>\n<pre>108 (100.0%) -- js-compartments\r\n\u251c\u2500\u2500102 (94.44%) \u2500\u2500 system\r\n\u2514\u2500\u2500\u2500\u25006 (05.56%) \u2500\u2500 user\r\n\r\n3,900,832 B (100.0%) -- window-objects\r\n\u251c\u2500\u25002,047,712 B (52.49%) -- layout\r\n\u2502\u00a0 \u251c\u2500\u25001,436,464 B (36.82%) \u2500\u2500 style-sets\r\n\u2502\u00a0 \u251c\u2500\u2500\u2500\u2500402,056 B (10.31%) \u2500\u2500 pres-shell\r\n\u2502\u00a0 \u251c\u2500\u2500\u2500\u2500100,440 B (02.57%) \u2500\u2500 rule-nodes\r\n\u2502\u00a0 \u251c\u2500\u2500\u2500\u2500\u250062,400 B (01.60%) \u2500\u2500 style-contexts\r\n\u2502\u00a0 \u251c\u2500\u2500\u2500\u2500\u250030,464 B (00.78%) \u2500\u2500 pres-contexts\r\n\u2502\u00a0 \u251c\u2500\u2500\u2500\u2500\u250010,400 B (00.27%) \u2500\u2500 frames\r\n\u2502\u00a0 \u251c\u2500\u2500\u2500\u2500\u2500\u25002,816 B (00.07%) \u2500\u2500 line-boxes\r\n\u2502\u00a0 \u2514\u2500\u2500\u2500\u2500\u2500\u25002,672 B (00.07%) \u2500\u2500 text-runs\r\n\u251c\u2500\u25001,399,904 B (35.89%) \u2500\u2500 style-sheets\r\n\u2514\u2500\u2500\u2500\u2500453,216 B (11.62%) -- dom\r\n\u00a0\u00a0\u00a0\u00a0 \u251c\u2500\u2500319,648 B (08.19%) \u2500\u2500 element-nodes\r\n\u00a0\u00a0\u00a0\u00a0 \u251c\u2500\u2500123,088 B (03.16%) \u2500\u2500 other\r\n\u00a0\u00a0\u00a0\u00a0 \u251c\u2500\u2500\u2500\u25008,880 B (00.23%) \u2500\u2500 text-nodes\r\n\u00a0\u00a0\u00a0\u00a0 \u251c\u2500\u2500\u2500\u25001,600 B (00.04%) \u2500\u2500 comment-nodes\r\n\u00a0\u00a0\u00a0\u00a0 \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u25000 B (00.00%) \u2500\u2500 cdata-nodes<\/pre>\n<p>This change improves the presentation of measurements that cross-cut those in the &#8220;explicit&#8221; tree.\u00a0 I intend to modify a number of the JS engine memory reports to take advantage of this change.<\/p>\n<p>One interesting bug was <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=759966\">this one<\/a>, where various people were seeing multiple compartments for the same site in about:compartments, as the following excerpt shows.<\/p>\n<pre>https:\/\/bugzilla.mozilla.org\/\r\nhttps:\/\/bugzilla.mozilla.org\/, about:blank<\/pre>\n<p>It turns out this is not a bug.\u00a0 The sites in question contain an empty iframe that doesn&#8217;t specify a URL, and so the memory reporters are doing exactly the right thing.\u00a0 Still, a useful case to know about when reading about:compartments.<\/p>\n<h3>Add-ons<\/h3>\n<p>Justin Lebar fixed the <a href=\"https:\/\/developer.mozilla.org\/en\/FUEL\">FUEL API<\/a>, which is used by numerous add-ons including Test Pilot and PDF.js, so that it <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=750454\">doesn&#8217;t leak most of the objects it creates<\/a>.\u00a0 This leak caused 10+ minute shut-down times(!) for one user, so it&#8217;s a good one to have fixed.<\/p>\n<p>Kyle Huey briefly <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=751999\">broke<\/a> his own <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=695480\">Hueyfix<\/a>, and then <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=752468\">fixed<\/a> it.\u00a0 You had us worried for a bit there, Kyle!<\/p>\n<p>asgerklasker <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=747167\">fixed a leak in the HttpFox add-on that caused zombie compartments<\/a>.<\/p>\n<h3>Miscellaneous<\/h3>\n<p>I <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=634444\">restricted the amount of context that is shown in JavaScript error messages<\/a>.\u00a0 This fixed a longstanding bug where if you had enabled the <code>javascript.options.strict<\/code> option in about:config, and you had the error console open or Firebug installed, memory consumption would spike dramatically when viewing pages that contain JavaScript code that triggered many strict warnings.\u00a0 This bug manifested rarely, but would bring Firefox to its knees when it did.<\/p>\n<p>Asaf Romano <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=758894\">fixed a leak that caused a zombie compartment if you used the &#8220;Highlight All&#8221; checkbox when doing a text search in a page<\/a>.<\/p>\n<p>Mike Hommey finished <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=580408\">importing the new version of jemalloc into the Mozilla codebase<\/a>, and then <a href=\"http:\/\/glandium.org\/blog\/?p=2581\">wrote about it<\/a>.\u00a0 The new version is currently disabled, but we hope to <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=762449\">turn it on<\/a> soon.\u00a0 Preliminary experiments indicate that the new version is unlikely to affect performance or memory consumption much.\u00a0 However, it will be good to be on a version that is in sync with the upstream version, instead of having a highly hacked Mozilla-specific version.<\/p>\n<p>Justin Lebar wrote <a href=\"http:\/\/jlebar.com\/2012\/5\/30\/A_ghost_story.html\">a nice blog post explaining what &#8220;ghost windows&#8221; are, and how we&#8217;ve used them to gauge some recent leak fixes<\/a>.<\/p>\n<p>Till Schneidereit f<a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=758278\">ixed a garbage collection defect<\/a> that could cause memory usage to <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=756549\">spike in certain cases involving Firefox Sync<\/a>.<\/p>\n<p>LifeHacker published <a href=\"http:\/\/lifehacker.com\/5917714\/browser-speed-tests-chrome-19-firefox-13-internet-explorer-9-and-opera-1164\">a new browser performance comparison<\/a> which looked at Firefox 13, Chrome 19, IE9, and Opera 11.64.\u00a0 Firefox did the best overall and also won both the memory consumption tests.\u00a0 I personally take these kinds of comparisons with a huge bucket of salt.\u00a0 Indeed, quoting from the article:<\/p>\n<blockquote><p>Our tests aren&#8217;t the most scientific on the planet, but they do reflect a relatively accurate view of the kind of experience you&#8217;d get from each browser, speed-wise.<\/p><\/blockquote>\n<p>If you ask me, the text before the &#8220;but&#8221; contradicts the rest of the sentence.\u00a0 What I found more interesting was the distinct lack of &#8220;lolwut everyone knows Chrome is faster than Firefox&#8221; comments, which I&#8217;m used to seeing when Firefox does well in these kinds of articles.<\/p>\n<h3>Bug Counts<\/h3>\n<p>Here are the current bug counts.<\/p>\n<ul>\n<li>P1: 25 (-1\/+3)<\/li>\n<li>P2: 88 (-3\/+6)<\/li>\n<li>P3: 106 (-0\/+4)<\/li>\n<li>Unprioritized: 2 (-2\/+2)<\/li>\n<\/ul>\n<p>Nothing too exciting there.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Memory Reporting Nathan Froyd added much more detail to the DOM and layout memory reporters, as the following example shows. \u251c\u2500\u25003,268,944 B (03.76%) &#8212; window(http:\/\/www.reddit.com\/) \u2502\u00a0 \u251c\u2500\u25001,419,280 B (01.63%) &#8212; layout \u2502\u00a0 \u2502\u00a0 \u251c\u2500\u2500\u2500\u2500403,904 B (00.46%) \u2500\u2500 style-sets \u2502\u00a0 \u2502\u00a0 \u251c\u2500\u2500\u2500\u2500285,856 B (00.33%) &#8212; frames \u2502\u00a0 \u2502\u00a0 \u2502\u00a0\u00a0\u00a0 \u251c\u2500\u2500\u250090,000 B (00.10%) \u2500\u2500 nsInlineFrame \u2502\u00a0 \u2502\u00a0 [&hellip;]<\/p>\n","protected":false},"author":139,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[15267,4550,119,30,4555,4544,4546,311],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts\/1980"}],"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=1980"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts\/1980\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/media?parent=1980"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/categories?post=1980"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/tags?post=1980"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}