827809 - [Browser][Memory usage] The case of creating multiple tabs in the browser app

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect)

Description

[John Shih]

Attachment: Screenshot

Now if keep creating taps (with arbitrary URI) in browser app will cause some situation:
1) stuck on the page (please see the attachment)
   In this case, only can press home key to quit the app
   and the hole system will be very buggy
2) Cause the b2g process crash
   In this case, the b2g process will restart 
   and the hole system will also be very buggy (react very slow)

I think the very root reason is that the browser app is now running as a part of b2g process, and every tab within the browser is a isolated process which may occupy at least 1 MB memory
and now seems have no any mechanism to handle this case

Comment 1

[John Shih]

seems the memory test didn't cover this case as well

Comment 2

[Justin Lebar (not reading bugmail)]

I still think it's a mistake to run each tab in a new process.

Comment 3

[John Shih]

may it's due to the security concern, and it's also why now the browser app can't run as OOP

Comment 4

[Justin Lebar (not reading bugmail)]

(In reply to John Shih from comment #3)
> may it's due to the security concern, and it's also why now the browser app
> can't run as OOP

The browser app could run as OOP, but then it would run in the same process as its tabs, because we can't have nested child processes.

So we decided that it would be better if the browser app ran in a separate process from its tabs.  That means that the browser app must run in the main process.

Comment 5

[John Shih]

(In reply to Justin Lebar [:jlebar] from comment #4)
> (In reply to John Shih from comment #3)
> > may it's due to the security concern, and it's also why now the browser app
> > can't run as OOP
> 
> The browser app could run as OOP, but then it would run in the same process
> as its tabs, because we can't have nested child processes.
> 
> So we decided that it would be better if the browser app ran in a separate
> process from its tabs.  That means that the browser app must run in the main
> process.

hmm, that's what I mean
so based on this design, I think we should concern about this issue
unless we decide not to ran each tab is a single process (but still need to assure the security e.g, cookie isolation)

Comment 6

[Nicholas Nethercote [inactive]]

> every tab within the browser is a isolated process
> which may occupy at least 1 MB memory

1 MB sounds optimistic.  Isn't the minimum per-process memory consumption more like 5--10 MB?

I too think the one-process-per-browser-tab choice is... interesting.

Comment 7

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

What's the memory requirement / workload / test here?

Comment 0 (1) sounds like a gaia bug.

Does anyone know what's happening in comment 0 (2)?  Whether it's OOM or a "normal" crash it's very serious, but which it is depends on how we track it.

FTR, we're doing process-per-app, and because of the way "bookmark" and e.me apps work, we're incidentally tied to process-per-tab with current technology.  I honestly don't care much about the multi-tab use case, but of course we shouldn't crash from dumb bugs there.

Comment 8

[John Shih]

For multiple apps case, now when keep creating apps, system will automatically kill background apps to make space for foreground apps

but in multiple taps case, there is no mechanism to handle it
so even it cause crash, all the tabs (process) will still be there
and thus the whole system becomes very slow

Comment 9

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

I'm a bit confused ... are we discussing a workload that creates many popup windows (which will look like tabs in the browser) from one original tab, or a workload where the user creates many tabs themself?

Comment 10

[John Shih]

I think is the second one
popup windows can be seen in the cardview and do not have this problem (I've tested with add multiple website to homescreen and open all of these, system killed the background popup wiondows automatically)

each tap in a browser runs as a process but can not be viewed in the cardview, so the load-balance mechanism can not help on it (this is what I thought..)

Comment 11

[John Shih]

seems like the browser has a high priority and can not be killed by system.

I think the load-balance mechanism needs to be applied in the browser app

Comment 12

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

That's correct: the browser UI isn't killed on low memory because it's not a separate process, but all the tabs can be killed independently.

Comment 13

[Justin Lebar (not reading bugmail)]

> we're incidentally tied to process-per-tab with current technology.

I think we could change this if we had your blessing.

Comment 14

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

I don't have a particularly strong opinion either way for browser tabs (i.e. don't care), but if you have a small and safe patch in mind with demonstrable gain, by all means! ;)

Comment 15

[John Shih]

I suggest we should have the mechanism like:
* When user keep creating tabs and cause OOM or exceed particular usage, the previous tab could leave with only seen on UI but the corresponding process is killed

* When user try to switch to the previous tab that has been killed, a new process will be created and load the same URL

Comment 16

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Yep, that's what we do currently :).

Comment 17

[Cody Roesch [:croesch]]

UCID browser-093
Testcase found here https://moztrap.mozilla.org/results/case/61201/

Comment 18

[sarsenyev]

It's works for me on "Unagi"
Build ID:20130115070201, Kernel Dec 5