801799 - Somehow reduce analysis-temporary memory usage on B2G

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Justin Lebar (not reading bugmail)]

Attachment: about:memory dump after steps in comment 0 (extract, open about:memory, load with button at bottom of page)

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?

Comment 1

[Justin Lebar (not reading bugmail)]

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

Comment 2

[Brian Hackett [Laid off!]]

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?

Comment 3

[Nicholas Nethercote [inactive]]

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.

Comment 4

[Nicholas Nethercote [inactive]]

Bug 781657 has landed on inbound.

bhackett, how do we enable and control the more aggressive analysis-temporary purging?

Comment 5

[Brian Hackett [Laid off!]]

(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.

Comment 6

[Nicholas Nethercote [inactive]]

> 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.

Comment 7

[Nicholas Nethercote [inactive]]

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

Comment 8

[Justin Lebar (not reading bugmail)]

(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!

Comment 9

[Justin Lebar (not reading bugmail)]

This looks much better now in my profiles.