Closed
Bug 979687
Opened 10 years ago
Closed 10 years ago
[tarako][v1.3t]enable OOP Of browser app , so LMK can kill browser app when memory low
Categories
(Firefox OS Graveyard :: General, defect, P2)
Tracking
(b2g-v1.3T affected)
RESOLVED
WONTFIX
1.4 S5 (11apr)
Tracking | Status | |
---|---|---|
b2g-v1.3T | --- | affected |
People
(Reporter: ying.xu, Unassigned)
Details
(Keywords: perf, Whiteboard: [c=memory p= s=2014.04.11 u=tarako])
Right now , browser app is running in the main process. In that case , it can not be killed by Low memory killer. It's a problem for low memory device such as tarako(128M). But, I find there still be some bugs, such as Bug 761935 - (nested-processes) Tracking: Support nested content processes
Comment 1•10 years ago
|
||
That will not happen in 1.3T. Note that browser tabs run out of process, which is what matter most usually. If we get memory-pressure notifications to propagate properly again, we could also remove the browser app iframe under these conditions.
blocking-b2g: 1.3T? → ---
(In reply to Fabrice Desré [:fabrice] from comment #1) > That will not happen in 1.3T. Note that browser tabs run out of process, > which is what matter most usually. If we get memory-pressure notifications > to propagate properly again, we could also remove the browser app iframe > under these conditions. OK,even the browser app iframe can be removed under the memory-pressure notification. But according to current LMK parameters set, the memory-pressure notification would be fired after kill all of the background apps. The behavior is not what we want. We want kill the app consuming memory most and used least recently.
Comment 3•10 years ago
|
||
(In reply to ying.xu from comment #2) > OK,even the browser app iframe can be removed under the memory-pressure > notification. > > But according to current LMK parameters set, the memory-pressure > notification would be fired after kill all of the background apps. That's correct, but we are revisiting when we trigger these in bug 972130. That should make things work as we want. We'll still need some gaia changes to get rid of the browser frame. > The behavior is not what we want. We want kill the app consuming memory most > and used least recently. I agree - It's not easy when we have some apps in process and some out of process though.
Updated•10 years ago
|
status-b2g-v1.3T:
--- → affected
Keywords: perf
Comment 4•10 years ago
|
||
Ying Xu, do you still see this problem now that bug 972130 has landed?
Flags: needinfo?(ying.xu)
Updated•10 years ago
|
Priority: -- → P2
Whiteboard: [c=memory p= s= u=tarako]
I can confirm the browser app is OOP now.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(ying.xu)
Resolution: --- → FIXED
Comment 6•10 years ago
|
||
The tabs are OOP, not the brwoser app itself.
Updated•10 years ago
|
Whiteboard: [c=memory p= s= u=tarako] → [c=memory p= s=2014.04.11 u=tarako]
OH,sorry.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 8•10 years ago
|
||
No worries, I'm fine with closing this bug. There's no chance to move the browser app OOP for 1.3t. We still could kill it on memory pressure when the app is not in the foreground.
Status: REOPENED → NEW
Comment 9•10 years ago
|
||
Closing as per comment 8. If that's an error, please comment and reopen.
Status: NEW → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → WONTFIX
Updated•10 years ago
|
Target Milestone: --- → 1.4 S5 (11apr)
You need to log in
before you can comment on or make changes to this bug.
Description
•