1308895 - [e10s-multi] browser test should use an existing content process for starting the next test

Status: RESOLVED FIXED

(Testing :: Mochitest, defect)

Description

[Gabor Krizsanits (INACTIVE)]

We want to turn on multiple content processes on nightly. Currently starting up a content process is slower than it should be, especially in debug builds.

For tests that are already close to hit timeouts this extra overhead can be an issue.

Forcing them to use single content process at the beginning of the test could be a solution but it turns out there is a problem with that: before each test we spawn a new tab and remove the last one open (even for the first test) [1]. This triggers the test to run in a fresh content process, and even if we force it to not spawn any more that adds an overhead of loading in a bunch of remote scripts while the test is already started.

This also will slow all the test that do not open any extra tabs unnecessary so to avoid that we have to figure out a way to open this new fresh tab in the same content process as the one we close.

[1]: http://searchfox.org/mozilla-central/source/testing/mochitest/browser-test.js#297

Comment 1

[(not currently active) Ted Mielczarek]

What's your ideal behavior here? Should we use a single content process for everything except for tests that want to explicitly open a tab in a new content process? If so, it seems like setting dom.ipc.processCount to 1 in the prefs and adding an API somewhere to allow launching a new content process should be sufficient.

Comment 2

[Gabor Krizsanits (INACTIVE)]

Ideally I would not create a new content process for the default tab of the test, but for every new tab the test creates. So:

1: I want all tests that use multiple tabs to run with multiple content processes on by default (and opt-out the ones we have problems with).
2: For tests that use only one tab for their entire session, I do not want to affect them at all
3: And most importantly, if a test opt-out from multiple content processes, by setting dom.ipc.processCount to 1, I do not want to affect them either.

So for 2 and 3 we need to make sure that the first tab of the tests, runs in an already "warmed-up" existing content process.

Does that make sense?

Comment 3

[(not currently active) Ted Mielczarek]

Yes, OK, that makes sense. I don't think we have existing APIs to say "create this tab in this content process", do we? If we did, we could simply make the browser harness use that to load the tests into an existing content process. Then other tests would just obey the dom.ipc.processCount pref.

Comment 4

[Gabor Krizsanits (INACTIVE)]

I think we might have something for that already... Blake, have you or Mike implemented an API lately that we could use here or should I add something?

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #4)
> I think we might have something for that already... Blake, have you or Mike
> implemented an API lately that we could use here or should I add something?

If you set .relatedBrowser on the browser, we should use the same process for both browsers. See [1] for an example of where it's used.

[1] http://searchfox.org/mozilla-central/rev/3e03a4064eb585d96f28023785a5c242969878a6/toolkit/components/viewsource/ViewSourceBrowser.jsm#189

Comment 6

[Gabor Krizsanits (INACTIVE)]

Attachment: reuse process in browser-test.js

Comment 7

[Gabor Krizsanits (INACTIVE)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=6a6001971c98

Comment 8

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 8799861 [details] [diff] [review]
reuse process in browser-test.js

Review of attachment 8799861 [details] [diff] [review]:
-----------------------------------------------------------------

::: testing/mochitest/browser-test.js
@@ +309,5 @@
>        gBrowser.removeTab(gBrowser.selectedTab, { skipPermitUnload: true });
>        gBrowser.stop();
>      }
>  
> +    this.firstTime = false;

What's this for?

Comment 9

[Gabor Krizsanits (INACTIVE)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/8df85989b975c0d32d9a0ad78066576b803cf858
Bug 1308895 - Reuse process in browser-test.js. r=mrbkap

Comment 10

[Gabor Krizsanits (INACTIVE)]

https://hg.mozilla.org/projects/ash/rev/a3441e5ff8f38605cd0cf8cd26083970ee5bd4b4
Bug 1308895 - Reuse process in browser-test.js. r=mrbkap

Comment 11

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/8df85989b975

Comment 12

[Gabor Krizsanits (INACTIVE)]

https://hg.mozilla.org/projects/ash/rev/32ef38e85b7cfd4de35e3f0bd2b3ac145a31b29e
Bug 1308895 - Force single content process for slow tests. r=me

Comment 13

[Gabor Krizsanits (INACTIVE)]

https://hg.mozilla.org/projects/ash/rev/51950259d4b4dbd1e51c81c44e050ad9684d8313
Bug 1308895 - part2: Force single content process for slow tests. r=me