[meta] Android killing content process aggressively on some devices (low on memory)
Categories
(GeckoView Graveyard :: Sandboxing, defect, P2)
Tracking
(Not tracked)
People
(Reporter: sebastian, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
(Keywords: meta, Whiteboard: [fenix:p1] [geckoview:2022h2?])
I was debugging the following Fenix issue where users describe that when switching tabs the page always reloads:
https://github.com/mozilla-mobile/fenix/issues/12731
At first I thought our memory trimming code in AC (that suspends tabs) was the culprit. But even when this is disabled I see it happen basically any time I switch tabs on my Nexus 9. Most users in this issue are using a Samsung S8.
Further debugging I noticed that Android calls Application.onTrimMemory()
on the Application
object of the content process. After giving the final warning with TRIM_MEMORY_COMPLETE Android kills the content process. We keep the state of all tabs and the next time the user switches to a tab we lazily restore it - which visually looks like a reload. Then there are again "too many" tabs and the content process gets killed after multiple warnings and the next switch again looks like a reload.
I opened a PR to further reduce our own memory trimming on the AC side. However that does not affect this killing of the content process and I wonder what we can do in this case?
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 1•4 years ago
|
||
Comment 2•4 years ago
|
||
Any update on progress with this :sebastian?
Reporter | ||
Comment 3•4 years ago
|
||
Replied on the GitHub issue. @Aaron: Also feel free to ping me on Slack/Zoom, if that resolves this quicker. :)
Reporter | ||
Comment 4•4 years ago
|
||
Heh, just saw in my mails that Emily scheduled a meeting already. 👍
Updated•4 years ago
|
Comment 5•3 years ago
|
||
Out of curiosity, does anybody know how Chrome handles this problem? Do they suffer from the same problem, have they found this one weird trick that sidesteps this issue, do they benefit because vendors might commonly whitelist Chrome from their resource usage optimisation routines...?
Reporter | ||
Comment 6•3 years ago
|
||
(In reply to Jan Henning [:JanH] from comment #5)
Out of curiosity, does anybody know how Chrome handles this problem? Do they suffer from the same problem, have they found this one weird trick that sidesteps this issue, do they benefit because vendors might commonly whitelist Chrome from their resource usage optimisation routines...?
Not sure how Chrome handles this. But on my Nexus 9 tablet, where this happens on almost every tab switch, I can reproduce this in Chrome too (Tabs reload visually) - but it needs a some of more tabs to be opened before it reproduces.
Updated•3 years ago
|
Comment 7•3 years ago
|
||
Tentatively set this bug's priority to P2 so we review it for GV's 2022 H2 planning.
Comment 8•3 years ago
|
||
Irene, is this bug actionable? Do your other tab unloading fixes make this bug obsolete or fixed?
Comment 9•3 years ago
|
||
I think it's actionable, and I don't think it's fixed. At least, we need to check if it's still reproduces.
Comment 10•2 years ago
|
||
Requires investigation in H2 to see if the tab unloading fixes helped with this issue.
Comment 11•2 years ago
|
||
Dupe of bug 1752594
Comment 12•2 years ago
|
||
Moving content process management bugs to the new GeckoView::Sandboxing component.
Updated•6 months ago
|
Description
•