> 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.
The issue isn't compilation of code; that doesn't stick out in the memory reports. The issue seems to be mostly the overhead of the JS engine for each file (even if the file stores very little data, as BrowserElementParent does) and also the unavoidable inefficiency associated with assigning each worker its own runtime (in particular, the fact that this greatly increases fragmentation). > Using JS for infrequently executing code should be a memory win. If the JS team wants to own B2G memory usage from here on out and can commit the necessary resources to re-optimizing the JS engine specifically for B2G, then that's great, I'd love to see us test this hypothesis. Otherwise, we're leaving a huge amount of memory for B2G on the table when we have a solution in hand that requires zero heroics. I think that's folly. On Mon, Apr 22, 2013 at 10: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
