Memory Reporting
Nathan Froyd added much more detail to the DOM and layout memory reporters, as the following example shows.
├──3,268,944 B (03.76%) -- window(http://www.reddit.com/) │ ├──1,419,280 B (01.63%) -- layout │ │ ├────403,904 B (00.46%) ── style-sets │ │ ├────285,856 B (00.33%) -- frames │ │ │ ├───90,000 B (00.10%) ── nsInlineFrame │ │ │ ├───72,656 B (00.08%) ── nsBlockFrame │ │ │ ├───62,496 B (00.07%) ── nsTextFrame │ │ │ ├───42,672 B (00.05%) ── nsHTMLScrollFrame │ │ │ └───18,032 B (00.02%) ── sundries │ │ ├────259,392 B (00.30%) ── pres-shell │ │ ├────168,480 B (00.19%) ── style-contexts │ │ ├────160,176 B (00.18%) ── pres-contexts │ │ ├─────55,424 B (00.06%) ── text-runs │ │ ├─────45,792 B (00.05%) ── rule-nodes │ │ └─────40,256 B (00.05%) ── line-boxes │ ├────986,240 B (01.13%) -- dom │ │ ├──780,056 B (00.90%) ── element-nodes │ │ ├──156,184 B (00.18%) ── text-nodes │ │ ├───39,936 B (00.05%) ── other [2] │ │ └───10,064 B (00.01%) ── comment-nodes │ └────863,424 B (00.99%) ── style-sheets
Although these changes slightly improved the coverage of the reporters (i.e. they reduce “heap-unclassified” a bit), the more important effect is that they give greater insight into DOM and layout memory consumption. [Update: Nathan blogged about these changes.]
I modified the memory reporter infrastructure and about:memory to allow trees of measurements to be shown in the “Other Measurements” section of about:memory. The following excerpt shows two sets of measurements that were previously shown in a flat list.
108 (100.0%) -- js-compartments ├──102 (94.44%) ── system └────6 (05.56%) ── user 3,900,832 B (100.0%) -- window-objects ├──2,047,712 B (52.49%) -- layout │ ├──1,436,464 B (36.82%) ── style-sets │ ├────402,056 B (10.31%) ── pres-shell │ ├────100,440 B (02.57%) ── rule-nodes │ ├─────62,400 B (01.60%) ── style-contexts │ ├─────30,464 B (00.78%) ── pres-contexts │ ├─────10,400 B (00.27%) ── frames │ ├──────2,816 B (00.07%) ── line-boxes │ └──────2,672 B (00.07%) ── text-runs ├──1,399,904 B (35.89%) ── style-sheets └────453,216 B (11.62%) -- dom ├──319,648 B (08.19%) ── element-nodes ├──123,088 B (03.16%) ── other ├────8,880 B (00.23%) ── text-nodes ├────1,600 B (00.04%) ── comment-nodes └────────0 B (00.00%) ── cdata-nodes
This change improves the presentation of measurements that cross-cut those in the “explicit” tree. I intend to modify a number of the JS engine memory reports to take advantage of this change.
One interesting bug was this one, where various people were seeing multiple compartments for the same site in about:compartments, as the following excerpt shows.
https://bugzilla.mozilla.org/ https://bugzilla.mozilla.org/, about:blank
It turns out this is not a bug. The sites in question contain an empty iframe that doesn’t specify a URL, and so the memory reporters are doing exactly the right thing. Still, a useful case to know about when reading about:compartments.
Add-ons
Justin Lebar fixed the FUEL API, which is used by numerous add-ons including Test Pilot and PDF.js, so that it doesn’t leak most of the objects it creates. This leak caused 10+ minute shut-down times(!) for one user, so it’s a good one to have fixed.
Kyle Huey briefly broke his own Hueyfix, and then fixed it. You had us worried for a bit there, Kyle!
asgerklasker fixed a leak in the HttpFox add-on that caused zombie compartments.
Miscellaneous
I restricted the amount of context that is shown in JavaScript error messages. This fixed a longstanding bug where if you had enabled the javascript.options.strict 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. This bug manifested rarely, but would bring Firefox to its knees when it did.
Mike Hommey finished importing the new version of jemalloc into the Mozilla codebase, and then wrote about it. The new version is currently disabled, but we hope to turn it on soon. Preliminary experiments indicate that the new version is unlikely to affect performance or memory consumption much. 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.
Justin Lebar wrote a nice blog post explaining what “ghost windows” are, and how we’ve used them to gauge some recent leak fixes.
Till Schneidereit fixed a garbage collection defect that could cause memory usage to spike in certain cases involving Firefox Sync.
LifeHacker published a new browser performance comparison which looked at Firefox 13, Chrome 19, IE9, and Opera 11.64. Firefox did the best overall and also won both the memory consumption tests. I personally take these kinds of comparisons with a huge bucket of salt. Indeed, quoting from the article:
Our tests aren’t the most scientific on the planet, but they do reflect a relatively accurate view of the kind of experience you’d get from each browser, speed-wise.
If you ask me, the text before the “but” contradicts the rest of the sentence. What I found more interesting was the distinct lack of “lolwut everyone knows Chrome is faster than Firefox” comments, which I’m used to seeing when Firefox does well in these kinds of articles.
Bug Counts
Here are the current bug counts.
- P1: 25 (-1/+3)
- P2: 88 (-3/+6)
- P3: 106 (-0/+4)
- Unprioritized: 2 (-2/+2)
Nothing too exciting there.
