I was trying to reproduce the crash cited in bug 808517 from opening lots of tabs. I wasn't able to reproduce the crash, but I was able to cause the main process to use a lot of memory. It's likely that this was what was causing the whole-phone crash in bug 808517. When I exited the browser by pressing the home button, no icons rendered in the homescreen. When I held down the home button to kill the browser app, screenshots didn't appear. After I killed the browser app and re-opened it (by clicking on the place on the homescreen where the browser /should have/ been), the app didn't load; it just sat at a grey screen. I'll post a memory report + dmd results in a moment. This is bad behavior and should block. The path of least-resistance to fixing this may be simply to restrict how many tabs you can open.

The main process is using 58MB of RSS, with 18mb of heap-unclassified (hooray for DMD). I see some familiar faces in this DMD report, but also some new ones.

I'm pretty convinced now that letting users open an arbitrary number of tabs in the browser (which runs in the main process) is a Bad Idea. Can we place a limit here and save ourselves some grief? There's of course prior art here that I don't need to be explicit about.

Why are the tabs triggering high memory usage in the browser? This should be pretty much the same scenario as the gaia window manager. What's different about browser tabs compared to app windows?

> Why are the tabs triggering high memory usage in the browser? I haven't gone through and filed bugs on all the culptits yet, but feel free to open the memory report attached and have a look at the dmd-b2g file. There are many culprits -- some which already have bugs, and some which do not yet -- nothing in particular sticks out at me as the one thing we need to fix. But even if we were to fix "everything", it's not clear that you wouldn't be able to open twice as many tabs and run into this same problem. > This should be pretty much the same scenario as the gaia window manager. What's > different about browser tabs compared to app windows? I agree; perhaps we should place a similar limit on the gaia window manager, if one can manifest the same problem.

At about how many tabs does performance drop? (or is that the wrong question, because it presumably has something to do with the kind of sites you're opening?). I'm wondering if the theoretical limit is so high that it's unlikely that our users (who probably aren't even used to browsing on phones) will even hit it. For comparison, we don't have a tab limit on Fennec, but we "close" old pages when we hit a low memory warning and open them again when the user goes back to the tab.

> At about how many tabs does performance drop? (or is that the wrong question, because it presumably > has something to do with the kind of sites you're opening?). It definitely has to do with the kind of site you're opening. I can open ~8 copies of the Google front page before the phone starts performing noticeably worse. But I haven't been able to reproduce the total breakage described in comment 0. > For comparison, we don't have a tab limit on Fennec, but we "close" old pages when we hit a low > memory warning and open them again when the user goes back to the tab. In B2G, each browser tab runs in its own process. (This is a relatively new development.) So in theory when we run low on memory we'll kill old tabs. This manifests as a tab crash. I can no longer reproduce this bug on my phone, so I guess we can just close it. Maybe I had a bad build. :-/

Comment 0 sounds suspiciously like bug 820702. (In reply to Justin Lebar [:jlebar] from comment #6) > > At about how many tabs does performance drop? (or is that the wrong question, because it presumably > > has something to do with the kind of sites you're opening?). > > It definitely has to do with the kind of site you're opening. > > I can open ~8 copies of the Google front page before the phone starts > performing noticeably worse. That is definitely not expected. Those guys shouldn't be doing anything, and timers should be throttled by !docshell.active. If you could grab a profile that'd be great, but I agree that we should file a followup for this.

> That is definitely not expected. It seems like GC pauses or something, subjectively. It does not seem like the kind of issue which would block release, so I'm not inclined to dig in too deeply at the moment. Last I checked, the profiler is basically useless because it only gets the innermost C++ stack frame.

GC pauses in the master process or in the subprocesses?

(In reply to Chris Jones [:cjones] [:warhammer] from comment #9) > GC pauses in the master process or in the subprocesses? The browser seemed to be freezing, so I'd guess in the master process. But I wouldn't put a lot of weight on this subjective recollection of mine.

ok. let me know if any additional ux decision needs to be made regarding limiting the number of tabs. Slowing down at ~8 tabs is pretty bad performance :(

> Slowing down at ~8 tabs is pretty bad performance :( I'm not usually a glass-half-full kind of person, but I think we deserve some credit due to the fact that that we can open up /nine Gecko processes/ on a device with ~100mb of usable RAM. We shouldn't expect this device to handle arbitrarily many tabs like your desktop.