We’ve been chipping away at memory use of Firefox 4 for a couple of
\nmonths now, with good results.\u00a0 Recently, though, I’ve been wondering
\nif we’re measuring the right things.\u00a0 It seems to me there’s two
\nimportant things to measure:<\/p>\n
Trying to gauge responsiveness by looking at peak RSS figures strikes
\nme as a losing prospect.\u00a0 The RSS values are set by some more-or-less
\nopaque kernel page discard algorithm, and depend on the behaviour of
\nall processes in the system, not just Firefox.\u00a0 Worse, it’s uninformative:
\nwe get no information about which parts of our code base are causing
\npaging.<\/p>\n
So I hacked up a VM profiler.\u00a0 This tells me the page fault behaviour
\nwhen running Firefox using a given amount of real memory.\u00a0 It isn’t as
\nbig a task as it sounds, since we already have 99.9% of the required
\ncode in pace: Valgrind’s Cachegrind tool.\u00a0 It just required replacing
\nthe cache simulator with a virtual-to-physical address map simulator.<\/p>\n
The profiler does a pretty much textbook pseudo-LRU clock algorithm
\nsimulation.\u00a0 It differentiates between page faults caused by data and
\ninstruction accesses, since these require different fixes — make the
\ndata smaller vs make the code smaller.\u00a0 It also differentiates between
\nclean (page unmodified) and dirty (page modified, requires writeback)
\nfaults.<\/p>\n
Here are some preliminary results.\u00a0 Bear in mind the profiler has only
\njust started to work, so the potential for bogosity is still large.<\/p>\n
First question is: we know that 4.0 uses more memory than 3.6.x.\u00a0 But
\ndoes that result in more paging?\u00a0 I profiled both, loading 5 cad-comic
\ntabs (http:\/\/www.cad-comic.com\/cad\/random) and idling for a while, for
\nabout 8 billion instructions.\u00a0 Results, simulating 100MB of real memory:<\/p>\n
3.6.x, release build, using jemalloc:<\/p>\n
VM I accesses: 8,250,840,547\u00a0 (3,186 clean faults + 350 dirty faults)
\nVM D accesses: 3,089,412,941\u00a0 (5,239 clean faults + 552 dirty faults)<\/p>\n
M-C, release build, using jemalloc:<\/p>\n
VM I accesses: 8,473,182,041\u00a0 ( 8,140 clean faults +\u00a0 4,979 dirty faults)
\nVM D accesses: 3,372,806,043\u00a0 (22,720 clean faults + 14,335 dirty faults)<\/p>\n
Apparently it does page more.\u00a0 Most of the paging is due to data
\nrather than instruction accesses.\u00a0 Requires further investigation.<\/p>\n
Second question is: where does that paging come from?\u00a0 Are we missing 18% ish of the faults come from js::Shape::trace.<\/p>\n And quite a few come from js::mjit::JITScript::purgePICs (two We’ve been chipping away at memory use of Firefox 4 for a couple of months now, with good results.\u00a0 Recently, though, I’ve been wondering if we’re measuring the right things.\u00a0 It seems to me there’s two important things to measure: … Continue reading<\/a><\/p>\n","protected":false},"author":240,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/jseward\/wp-json\/wp\/v2\/posts\/74"}],"collection":[{"href":"https:\/\/blog.mozilla.org\/jseward\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mozilla.org\/jseward\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/jseward\/wp-json\/wp\/v2\/users\/240"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/jseward\/wp-json\/wp\/v2\/comments?post=74"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/jseward\/wp-json\/wp\/v2\/posts\/74\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/jseward\/wp-json\/wp\/v2\/media?parent=74"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/jseward\/wp-json\/wp\/v2\/categories?post=74"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/jseward\/wp-json\/wp\/v2\/tags?post=74"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nany easy wins?\u00a0 From a somewhat longer run with bigger workload, I got
\nthis (w\/ apologies for terrible formatting):
\n
\nDa (# data accesses)
\n.\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Dfc (# clean data faults)
\n.\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 function
\n------------------------------------------
\n18,921,574,436\u00a0\u00a0 382,023\u00a0\u00a0 PROGRAM TOTALS<\/code><\/p>\n <\/code><\/p>\n.\u00a0\u00a0 19,339,625\u00a0 \u00a0 60,583\u00a0\u00a0 js::Shape::trace
\n.\u00a0\u00a0\u00a0 2,228,649\u00a0\u00a0\u00a0 51,635\u00a0\u00a0 JSCompartment::purge
\n.\u00a0\u00a0 32,583,809\u00a0\u00a0\u00a0 22,223\u00a0\u00a0 js_TraceScript
\n.\u00a0\u00a0 16,306,348\u00a0\u00a0\u00a0 18,404\u00a0\u00a0 js::mjit::JITScript::purgePICs
\n.\u00a0\u00a0 18,160,249\u00a0\u00a0\u00a0 12,847\u00a0\u00a0 js::mjit::JITScript::purgePICs
\n.\u00a0\u00a0 52,155,631\u00a0\u00a0\u00a0 11,727\u00a0\u00a0 memset
\n.\u00a0\u00a0 27,229,391\u00a0\u00a0\u00a0 10,813\u00a0\u00a0 js::PropertyTree::sweepShapes
\n.\u00a0 120,482,308\u00a0\u00a0\u00a0 10,256\u00a0\u00a0 js::gc::MarkChildren
\n.\u00a0 138,049,859\u00a0\u00a0 \u00a0 9,134\u00a0\u00a0 memcpy
\n.\u00a0\u00a0\u00a0 2,228,649\u00a0\u00a0\u00a0\u00a0 8,779\u00a0\u00a0 JSCompartment::sweep
\n.\u00a0\u00a0 179,083,731\u00a0\u00a0\u00a0 8,057\u00a0\u00a0 js_TraceObject
\n.\u00a0\u00a0\u00a0 6,269,454\u00a0\u00a0\u00a0\u00a0 5,949\u00a0\u00a0 js::mjit::JITScript::sweepCallICs
\n<\/code><\/p>\n
\nversions) and js::mjit::JITScript::sweepCallICs.\u00a0 According to Dave
\nAnderson and Chris Leary, there might be some opportunity to poke
\nthe code pages in a less jumping-around-y fashion.<\/p>\n","protected":false},"excerpt":{"rendered":"