1937836 - Investigate re-enabling process prelaunching (preallocation) on Android

Status: RESOLVED FIXED

(GeckoView :: General, enhancement)

Description

[Kaya [:kaya]]

The process prelauncing is disabled on Android. (see Bug 1447393).

With Fission coming up, to improve the pageload performance, we should consider enabling the process prelaunching to reduce the costs caused by spawning new content processes at the time of page loads.
Enabling the pref shows improvements in pageload performance for Fission up to 17% (see perfcompare).

In the scope of this ticket, we should investigate how stable process prelaunching is at the moment, and the required work -if any- to make it stable.

Comment 1

[Markus Stange [:mstange]]

Attachment: WIP: Bug 1937836 - Enable process preallocation on Android.

This should help applink startup performance because the content process
and the WebExtension process will be ready sooner.

Comment 2

[Markus Stange [:mstange]]

Attachment: Bug 1937836 - Enable process preallocation on Android. r=kaya

By itself, this patch will have the following effect: Once Gecko
has requested the first content process, after some delay, a
second content process will be preallocated on Android. This process
is used once a second tab is loaded or once a Fission-enabled site
is loaded. The process count limit in dom.ipc.processCount is
honored and no further processes will be preallocated once the limit
is reached.

Flipping this pref has no impact on startup times because Gecko's
PreallocatedProcessManager currently doesn't kick off preallocation
before the first time someone asks for a new content process, and
because it currently only ever kicks off a preallocation on idle.

However, in bug 1958065 and bug 1958327 we want to actually kick off
the content processes needed for startup at an earlier time, and we
need a place to store the handles to the preallocated processes. The
PreallocatedProcessManager seems like the right place to store these
handles, and we'll need the pref to be true at that point so that the
right code paths are exercised.

By flipping the pref now, we can front-load some of the risk of the
changes planned for bug 1958065 and bug 1958327.

Comment 3

[Markus Stange [:mstange]]

(In reply to Kaya [:kaya] from comment #0)

In the scope of this ticket, we should investigate how stable process prelaunching is at the moment, and the required work -if any- to make it stable.

I used a try build with this a bit and didn't notice any trouble. And I can't think of a reason there would be trouble - it's just launching the second content process a bit earlier. The preloader code paths are already exercised on desktop. The content process launching code paths are already exercised on Android once you load a second tab. There's not really any new source of risk here.

I think we should just flip the pref. If there are problems we'll notice them.

Comment 4

[Markus Stange [:mstange]]

(In reply to Kaya [:kaya] from comment #0)

With Fission coming up

Even when Fission is enabled, PreallocatedProcessManager only allocates processes until we hit the limit in dom.ipc.processCount. So at the moment we still won't have more than 2 content processes if we flip the dom.ipc.processPrelaunch.enabled pref.

Links to the code: PreallocatedProcessManagerImpl::CanAllocate() calls ContentParent::IsMaxProcessCountReached(DEFAULT_REMOTE_TYPE) which calls ContentParent::GetMaxProcessCount(DEFAULT_REMOTE_TYPE) which returns GetMaxWebProcessCount() which returns the value of the dom.ipc.processCount pref.

Comment 5

[Markus Stange [:mstange]]

https://treeherder.mozilla.org/jobs?repo=try&revision=3c9cac550148175502fcce16960ad40af2724fb4

Comment 6

[Markus Stange [:mstange]]

The try push is showing a fair amount of timeouts in the mda1+mda2 tests, i.e. the geckoview-mochitest-media tests, both on the regular Android x86-64 debug configuration, but particularly on the debug-isolated-process configuration.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

There is an r+ patch which didn't land and no activity in this bug for 2 weeks.
:sinker, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit BugBot documentation.

Comment 8

[Markus Stange [:mstange]]

This is blocked on investigating test failures.

Comment 9

[Thinker Li [:sinker]]

Markus,
I have tried on the trunk. I don't see any timeout on mda tests anymore.
Is this the only thing blocking this bug?

https://treeherder.mozilla.org/jobs?repo=try&duplicate_jobs=visible&revision=8d130bc59f1e00aa037027f73c6bf5aab7813eb0

Comment 10

[Markus Stange [:mstange]]

(In reply to Thinker Li [:sinker] from comment #9)

Is this the only thing blocking this bug?

Yes it is! Thanks for doing the try push.

From my side this is fine to land then! Kaya, are you ok with us landing it now?

Comment 11

[Kaya [:kaya]]

I retriggered some failing tasks. Looks fine to me as well. I think we can land.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/dc06efb4269a
https://hg.mozilla.org/integration/autoland/rev/04dfe9e6fdc9
Enable process preallocation on Android. r=kaya,geckoview-reviewers,nika

Comment 13

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/04dfe9e6fdc9

Comment 14

[Acasandrei Beatrice (needinfo me)]

(In reply to Pulsebot from comment #12)

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/dc06efb4269a
https://hg.mozilla.org/integration/autoland/rev/04dfe9e6fdc9
Enable process preallocation on Android. r=kaya,geckoview-reviewers,nika

Perfherder has detected a browsertime performance change from push 04dfe9e6fdc902882d1f8095d7dda1ce22216759.

If you have any questions, please reach out to a performance sheriff. Alternatively, you can find help on Slack by joining #perf-help, and on Matrix you can find help by joining #perftest.

Improvements:

Ratio	Test	Platform	Options	Absolute values (old vs new)	Performance Profiles
39%	vpl-h264 poster	android-hw-a55-14-0-aarch64-shippable	cold webrender	306.40 -> 187.66	Before/After
38%	vpl-vp9 poster	android-hw-a55-14-0-aarch64-shippable	cold fission webrender	300.24 -> 185.10	Before/After
38%	vpl-h264 poster	android-hw-a55-14-0-aarch64-shippable	cold fission webrender	303.47 -> 188.00	Before/After
37%	vpl-vp9 poster	android-hw-a55-14-0-aarch64-shippable	cold webrender	304.07 -> 190.54	Before/After
36%	vpl-av1 poster	android-hw-a55-14-0-aarch64-shippable	cold webrender	308.33 -> 198.83	Before/After
...	...	...	...	...	...
8%	vpl-vp9 lastFrame	android-hw-a55-14-0-aarch64-shippable	cold fission webrender	1,388.46 -> 1,275.96	Before/After

Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests.

If you need the profiling jobs you can trigger them yourself from treeherder job view or ask a performance sheriff to do that for you.

You can run all of these tests on try with ./mach try perf --alert 46777

The following documentation link provides more information about this command.