On 04/21/2013 04:51 PM, 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.
=== 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.
Once exact rooting of the browser is complete we can implement heap
defragmentation easily. Generational GC should help as well here.
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.
Our exact rooting work is at a spot right now where we could easily use
more hands to accelerate the process. The main problem is that the work
is easy and tedious: a hard sell for pretty much any hacker at mozilla.
Once this work is complete, however, we can get some level of
defragmentation working in a matter of weeks and generational in a
slightly longer time frame.
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.)
Are you saying JS is not perfect in every way? Release the hounds! :-)
More seriously, JS does have all the tools you need to get very close in
memory or execution speed to C++. The question of which of those tools
is easiest to use in any specific situation is more interesting.
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.
Well, I have to disagree a bit. I know Monkey Island is a weird and
special place to work, but the impossible does seem to happen here on a
strangely regular basis. Usually it even happens without any obvious
heroics.
=== 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?
I can't really agree or disagree without knowing why they use "too much"
memory. What I can say is that doing a complete rewrite is almost never
the right answer, particularly if we don't understand what we are trying
to solve in more detail.
-Terrence
-Justin
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
