The things on Justin's list do not appear to be infrequently running code. Wifi, RIL, Apps, mozbrowser, etc are going to be running all the time.
- Kyle On Mon, Apr 22, 2013 at 7:11 AM, Andreas Gal <andreas....@gmail.com> wrote: > JS is a big advantage for rapid implementation of features and it's > easier to avoid exploitable mistakes. Also, in many cases JS code > (bytecode, not data) should be slimmer than C++. Using JS for > infrequently executing code should be a memory win. I think I would > like to hear from the JS team on reducing memory use of JS and > disabling any compilation for infrequently running code before we give > up on it. > > Andreas > > Sent from Mobile. > > On Apr 22, 2013, at 7:05, Justin Lebar <justin.le...@gmail.com> wrote: > > > Of course attachments don't work great on newsgroups. I've uploaded > > the about:memory dumps I tried to attach to people.m.o: > > > > http://people.mozilla.org/~jlebar/downloads/merged.json.xz > > http://people.mozilla.org/~jlebar/downloads/unmerged.json.xz > > > > On Sun, Apr 21, 2013 at 7:51 PM, Justin Lebar <justin.le...@gmail.com> > 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. > >> > >> === Data === > >> > >> Right now about 50% (16mb) of the memory used by the B2G main process > >> immediately after rebooting is JS. It is my hypothesis that we could > greatly > >> reduce this by converting modules to C++. > >> > >> On our 256mb devices, we have about 120mb available to Gecko, so this > 16mb > >> represents 13% of all memory available to B2G. > >> > >> To break down the 16mb of JS memory, 8mb is from four workers: > ril_worker, > >> net_worker, wifi_worker (x2). 5mb of the 8mb is under "unused-arenas"; > this is > >> fragmentation in the JS heap. Based on my experience tackling > fragmentation in > >> the jemalloc heap, I suspect reducing this would be difficult. But > even if we > >> eliminated all of the fragmentation, we'd still be spending 3mb on > these four > >> workers, which I think is likely far more than we need. > >> > >> The other 8mb is everything else in the system compartment (all our > JSMs, > >> XPCOM components, etc). In a default B2G build you don't get a lot of > insight > >> into this, because most of the system compartments are squished > together to save > >> memory (bug 798491). If I set jsloader.reuseGlobal to false, the > amount of > >> memory used increases from 8mb to 15mb, but now we can see where it's > going. > >> > >> The list of worst offenders follows, but because this data was > collected with > >> reuseGlobal turned off, apply generous salt. > >> > >> 0.74 MB modules/Webapps.jsm > >> 0.59 MB anonymous sandbox from devtools/dbg-server.jsm:41 > >> 0.53 MB components/SettingsManager.js > >> 0.53 MB chrome://browser/content/shell.xul > >> 0.49 MB components/WifiWorker.js > >> 0.43 MB modules/DOMRequestHelper.jsm > >> 0.38 MB modules/XPCOMUtils.jsm > >> 0.34 MB RadioInterfaceLayer.js > >> 0.31 MB AppsUtils.jsm > >> 0.27 MB Webapps.js > >> 0.22 MB BrowserElementParent.jsm > >> 0.21 MB app://system.gaiamobile.org/index.html > >> > >> Many (but certainly not all) of these modules could be rewritten in C++. > >> > >> Beyond this list, it's death by a thousand cuts; there are 100 > compartments in > >> there, and they each cost a small amount. > >> > >> I've attached two about:memory dumps collected on my hamachi device > soon after > >> reboot, so you can examine the situation more closely, if you like. > >> merged.json was collected with the default config, and unmerged.json was > >> collected with jsloader.reuseGlobal set to false. > >> > >> Download and extract these files and then open them with the button at > >> the bottom > >> of about:memory in Nightly. > >> > >> (Before you ask: Most of the heap-unclassified in these dumps is > >> graphics memory, > >> allocated in drivers.) > >> > >> === Should we use JS because it's nicer than C++? === > >> > >> I recognize that in many ways JS is a more convenient language than > C++. But > >> that's besides the point here. The point is that in the environment > we're > >> targeting, our implementation of JS is too heavyweight. We can either > fix our > >> implementation or use less JS, but we can't continue using as much JS > as we > >> like without doing one of these two things. > >> > >> === Why not just make JS slimmer? === > >> > >> It's been suggested to me that instead of converting existing and > future JS > >> code to C++, we should focus on making our JS engine slimmer. Such > changes > >> would of course have the advantage of improving our handling of web > content on > >> B2G. > >> > >> I'm absolutely in favor of reducing JS memory usage, but I see this > effort as > >> orthogonal to the question of rewriting our current code and writing > our future > >> code in C++, for a few reasons. > >> > >> 1. Content JS does not run in the B2G main process, where the impact of > high > >> memory usage is strongest. We can probably tolerate higher memory > usage for > >> content JS than we can for main-process code. I think it makes sense > for our > >> JS team to focus their effort on optimizing for content JS, since > that's far > >> more widespread. > >> > >> 2. We have a large team of B2G engineers, some of whom could work > exclusively > >> on converting components from JS to C++. In contrast, we have a > relatively > >> small team of JS engineers, few of whom can work exclusively on > optimizing the > >> JS engine for B2G's use-cases. > >> > >> 3. I know people get in trouble at Mozilla for suggesting that it's > impossible > >> to do anything in JS, so I won't do that, but it seems to me that the > dynamic > >> semantics of JS make it very difficult to achieve the same degree of > memory > >> density as we do with C++. (We're talking about density of program > data as > >> well as code here.) > >> > >> At the very least, I'm pretty sure it's straightforward to > significantly reduce > >> our memory usage by rewriting code in C++, while it would probably take > >> engineering heroics to approach the same level of memory usage by > modifying the > >> JS engine. I don't think it's wise to bet the product on heroics, > >> given an alternative. > >> > >> === Conclusion === > >> > >> If we think that 256mb is a fad, then our current trajectory is probably > >> sustainable. But everything I have heard from management suggests that > we are > >> serious about 256mb for the foreseeable future. > >> > >> If we anticipate shipping on 256mb devices for some time, I think our > rate of > >> adding features written in JS is unsustainable. I think we should > shift the > >> default language for implementation of DOM APIs from JS to C++, and we > should > >> rewrite the parts of the platform that run on B2G in C++, where > possible. > >> > >> I'd start by converting these four workers. Do we agree this is a > place to > >> start? > >> > >> -Justin > > _______________________________________________ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
