On 03/07/2017 05:29 AM, Ben Kelly wrote:
On Mon, Mar 6, 2017 at 5:42 PM, Nicholas Nethercote <n.netherc...@gmail.com>
wrote:
On Tue, Mar 7, 2017 at 9:22 AM, Ben Kelly <bke...@mozilla.com> wrote:
These measurements are for full content processes. Many of the processes
in the above do not need all the chrome script we load in content processes
today.
That's good to know. But it would still be good to get measurements of
these slimmer processes, and check that they don't contain unnecessary
stuff, and decide what coordination is necessary between the different
process types (as kmag suggested elsewhere in the thread).
I think we should make measuring this and getting product sign-off a
requirement of riding the trains beyond nightly. The decision should weigh
the cost/benefit, though. We probably need to accept some memory
regression for the benefits we are getting. We just need to go in with
eyes open.
In general I think processes that rely on native code vs chrome script will
do better here. My impression is that the chrome script js heaps make it
more difficult for the processes to share memory compared to native code
pages. I could be wrong, though.
What you mean with "chrome script"? Any chrome JS?
There is frame script overhead per tab in child processes (around 340kB on my
machine) but then
we have also tons of jsms. I see 94 chrome compartments in a child process with
one tab.
And yes, that all is taking tons of memory. We really should move more code to
native.
One thing which we haven't, AFAIK, really investigated is to try to release
memory in background tabs more
aggressively. We could run compacting GC a tad more often if the process has
only background tabs.
Also, bfcache limits are per process, so the more we have processes, the more
we store pages in bfcache.
Maybe only-background-tabs process should evict all of its bfcache quite soon,
and not wait for up to 30mins.
etc.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
