To close the loop on this thread, the consensus here seems to be that 1. We should continue to make JS slimmer. This is a high priority for B2G even setting aside the memory consumption of B2G's chrome JS, since of course B2G runs plenty of content JS.
The memory profile of B2G is different from desktop -- small overheads matter more on B2G, and the consequences of using too much memory are more drastic. We should keep this in mind when working on JS in the future. 2. We should fix bug 829482 (run more shrinking GCs in workers). This will get us an easy 4-5mb in the main B2G process. This is a MemShrink:P1 and has been open for a while; I'd love some assistance with it. 3. We should rewrite these main-process workers in C++, if and when we have manpower. Even with bug 829482 fixed, the workers will still be some of the largest individual consumers of JS memory in B2G, and all of the JS folks I spoke with said that they thought they'd be unable to reduce the memory overhead of a worker significantly in the medium term. I filed bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=864927 https://bugzilla.mozilla.org/show_bug.cgi?id=864931 https://bugzilla.mozilla.org/show_bug.cgi?id=864932 4. It's worthwhile to at least look carefully at the biggest B2G chrome compartments and see whether we can reduce their size one way or another. I filed a metabug: https://bugzilla.mozilla.org/show_bug.cgi?id=864943 5. When writing new APIs, we should at least consider writing them in C++. JS should not be the default. Where things are super-easy in JS and super-annoying in C++, we should consider investing in our C++ infrastructure to make it more pleasant. Since not everyone reads this newsgroup, I'd appreciate assistance disseminating (5) in bugs. At the very least, we should ask patch authors to consider the alternatives before creating new JS modules that are enabled on B2G. I'm also going to post this summary to dev-b2g with a pointer back to this newsgroup. Thanks for your thoughts, everyone. -Justin On Mon, Apr 22, 2013 at 9:46 PM, Nicholas Nethercote <n.netherc...@gmail.com> wrote: > On Mon, Apr 22, 2013 at 6:35 PM, Justin Dolske <dol...@mozilla.com> wrote: >> >> That said, I think it's critically important that we're working to make JS a >> acceptable -- nay, _excellent_ -- language/runtime for application >> development for the long run. We can't tell a credible story about why >> people should write HTML5 apps, if we're tearing out swaths of JS in our own >> products. Sometimes dogfooding is unpleasant or hard, but that's the whole >> point. > > There's a big difference between apps on Firefox OS, which are likely > to have relatively short lifetimes and can be killed if they take up > too much memory, and the main process. Bad memory behaviour in the > main process is a much bigger deal, and it's something that's > happening right now with some frequency. > > Nick > _______________________________________________ > 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
