analysis-temporary memory accounts for ~10mb of memory usage on my device when I * reboot * open the browser * load nytimes.com I recall that we used to flush this memory on GC. Is that what we still do? Is that the only feasible way to erase this memory, or could we experiment flushing it more aggressively?

Impressively, we use more memory for analysis-temporary in the browser than for the GC heap! (Browser process) 23.81 MB (100.0%) -- js-main-runtime ├──20.19 MB (84.79%) -- compartments │ ├───7.49 MB (31.46%) ── analysis-temporary │ ├───6.79 MB (28.51%) -- gc-heap

The analysis-temporary memory should be pretty much wiped out on GC, and bug 778724 added functionality to allow purging analysis-temporary while retaining jitcode. The latter functionality is, however, disabled until the fix in bug 781657 lands. Is the patch for bug 778724 (bf07c6253287) in b2g?

I just talked to bhackett. Let me try to clarify things. Bug 778724 provided a knob that defines a threshold above which analysis-temporary can be discarded without also doing a GC or discarding JIT code. (And the consequence of lowering this threshold is that the analysis info may need to be regenerated later on, which takes extra time.) So it sounds great for fixing this problem. Bug 778724 landed in FF17 -- so it's in B2G -- but it's currently disabled and bug 781657 must land before it can be enabled. Bug 781657 isn't terribly invasive, and bhackett says he'll resurrect it and run it on the try server with an eye to landing it on m-c in the next day or so. Once that's done, I guess someone can experiment with the patch on B2G and see if it helps, and if it does, backport it to Aurora.

Bug 781657 has landed on inbound. bhackett, how do we enable and control the more aggressive analysis-temporary purging?

(In reply to Nicholas Nethercote [:njn] from comment #4) > Bug 781657 has landed on inbound. > > bhackett, how do we enable and control the more aggressive > analysis-temporary purging? Remove the preliminary return in TypeCompartment::maybePurgeAnalysis, and then the limit can be adjusted with the javascript.options.mem.analysis_purge_mb setting.

> Remove the preliminary return in TypeCompartment::maybePurgeAnalysis, and > then the limit can be adjusted with the > javascript.options.mem.analysis_purge_mb setting. Thanks! It looks like the default is 100MB (http://mxr.mozilla.org/mozilla-central/source/modules/libpref/src/init/all.js#744). For B2G that should be wound back significantly, though we should probably let bug 804891 land first before doing measurements.

Bug 804891 helped a lot. Do we still need to do more?

(In reply to Nicholas Nethercote [:njn] from comment #7) > Bug 804891 helped a lot. Do we still need to do more? I'll try to do some measurements, but I have a large backlog of stuff, so if anyone beats me to it, I will not complain!

This looks much better now in my profiles.