> How about pre-compiling JS in JITed form? While significant, it seems that memory used for script source isn't the biggest offender.
Full details are in the about:memory reports, http://people.mozilla.org/~jlebar/downloads/merged.json.xz http://people.mozilla.org/~jlebar/downloads/unmerged.json.xz but here's a teaser. This is the wifi worker. I think "script-sources" is code. Note that fragmentation (unused-arenas) is way too high, but even despite this the worker uses too much memory. > 2.38 MB (05.13%) -- worker(resource://gre/modules/wifi_worker.js, 0x45584800) > ├──1.77 MB (03.81%) -- gc-heap > │ ├──1.74 MB (03.74%) ── unused-arenas > │ └──0.03 MB (00.07%) -- (2 tiny) > │ ├──0.03 MB (00.07%) ── chunk-admin > │ └──0.00 MB (00.00%) ── unused-chunks > └──0.61 MB (01.32%) -- (3 tiny) > ├──0.26 MB (00.57%) -- runtime > │ ├──0.13 MB (00.27%) ── gc-marker > │ ├──0.06 MB (00.12%) ── jaeger-code > │ ├──0.04 MB (00.08%) ── runtime-object > │ ├──0.02 MB (00.03%) ── atoms-table > │ ├──0.01 MB (00.03%) ── script-sources > │ ├──0.01 MB (00.01%) ── unused-code > │ ├──0.00 MB (00.01%) ── dtoa > │ ├──0.00 MB (00.01%) ── stack > │ ├──0.00 MB (00.01%) ── temporary > │ ├──0.00 MB (00.00%) ── contexts > │ ├──0.00 MB (00.00%) ── script-filenames > │ ├──0.00 MB (00.00%) ── ion-code > │ ├──0.00 MB (00.00%) ── math-cache > │ └──0.00 MB (00.00%) ── regexp-code > ├──0.25 MB (00.54%) -- compartment(web-worker) > │ ├──0.13 MB (00.29%) -- gc-heap > │ │ ├──0.07 MB (00.15%) ── unused-gc-things [2] > │ │ ├──0.03 MB (00.06%) -- objects > │ │ │ ├──0.02 MB (00.04%) ── non-function > │ │ │ └──0.01 MB (00.02%) ── function > │ │ ├──0.02 MB (00.04%) ── shapes/tree > │ │ └──0.02 MB (00.03%) ── sundries [2] > │ ├──0.06 MB (00.13%) ── analysis-temporary > │ ├──0.03 MB (00.06%) ── other-sundries [2] > │ ├──0.02 MB (00.04%) ── objects-extra/slots > │ └──0.01 MB (00.02%) ── script-data > └──0.10 MB (00.22%) -- compartment(web-worker-atoms) > ├──0.09 MB (00.19%) -- gc-heap > │ ├──0.09 MB (00.18%) ── strings > │ └──0.00 MB (00.01%) ── sundries > └──0.01 MB (00.02%) ── other-sundries Here's the worst-offending compartment (webapps.js) with jsloader.reuseGlobal turned off. Recall that flipping this switch expands memory usage by a factor of 2, and not all pieces of the compartment are affected equally, so take this with salt. > 0.74 MB (01.60%) -- compartment([System Principal], > resource://gre/modules/Webapps.jsm) > ├──0.28 MB (00.61%) -- gc-heap > │ ├──0.10 MB (00.21%) ── unused-gc-things > │ ├──0.08 MB (00.17%) -- objects > │ │ ├──0.06 MB (00.12%) ── non-function > │ │ └──0.02 MB (00.04%) ── function > │ ├──0.05 MB (00.11%) ── strings > │ ├──0.03 MB (00.05%) ── shapes/tree > │ ├──0.02 MB (00.04%) ── scripts > │ └──0.01 MB (00.02%) ── sundries > ├──0.17 MB (00.36%) -- string-chars > │ ├──0.09 MB (00.20%) ── non-huge > │ └──0.08 MB (00.17%) -- huge > │ ├──0.04 MB (00.08%) ── string(length=9114, > "data:image//png;base64,iVBORw0KG...") [2] > │ └──0.04 MB (00.08%) ── string(length=9646, > "data:image//png;base64,iVBORw0KG...") [2] > ├──0.11 MB (00.23%) -- objects-extra > │ ├──0.09 MB (00.20%) ── slots > │ └──0.02 MB (00.03%) ── property-iterator-data > ├──0.07 MB (00.16%) ── script-data > ├──0.06 MB (00.13%) ── analysis-temporary > ├──0.02 MB (00.04%) ── shapes-extra/tree-tables > ├──0.02 MB (00.04%) ── other-sundries > └──0.02 MB (00.03%) ── cross-compartment-wrappers To me, this seems like death by a thousand cuts; there are /lots/ of little things that we'd need to improve. On Mon, Apr 22, 2013 at 10:31 AM, Mike Hommey <m...@glandium.org> wrote: > On Sun, Apr 21, 2013 at 07:51:18PM -0400, Justin Lebar wrote: >> I think we should consider using much less JS in the parts of Gecko that are >> used in B2G. I'd like us to consider writing new modules in C++ where >> possible, and I'd like us to consider rewriting existing modules in C++. >> >> I'm only proposing a change for modules which are enabled for B2G. For >> modules >> which aren't enabled on B2G, I'm not proposing any change. >> >> What I'd like to come out of this thread is a consensus one way or another as >> to whether we continue along our current path of writing many features that >> are >> enabled on B2G in JS, or whether we change course. >> >> Since most of these features implemented in JS seem to be DOM features, I'm >> particularly interested in the opinions of the DOM folks. I'm also >> interested >> in the opinions of JS folks, particularly those who know about the memory >> usage >> of our new JITs. >> >> In the remainder of this e-mail I'll first explain where our JS memory is >> going. Then I'll address two arguments that might be made against my >> proposal >> to use more C++. Finally, I'll conclude by suggesting a plan of action. > > How about pre-compiling JS in JITed form? That would require the JIT > form to be relocatable if they isn't already, and wouldn't work well on > platforms where we use different instructions depending on the actual > target processor, but I guess that could work on our ARM targets. I > however don't know how much less memory that would take. > > Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
