Closed Bug 979687 Opened 7 years ago Closed 7 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)

ARM
Gonk (Firefox OS)

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
blocking-b2g: --- → 1.3T?
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.
(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.
Ying Xu, do you still see this problem now that bug 972130 has landed?
Flags: needinfo?(ying.xu)
Priority: -- → P2
Whiteboard: [c=memory p= s= u=tarako]
I can confirm the browser app is OOP now.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(ying.xu)
Resolution: --- → FIXED
The tabs are OOP, not the brwoser app itself.
Whiteboard: [c=memory p= s= u=tarako] → [c=memory p= s=2014.04.11 u=tarako]
OH,sorry.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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
Closing as per comment 8. If that's an error, please comment and reopen.
Status: NEW → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → WONTFIX
Target Milestone: --- → 1.4 S5 (11apr)
You need to log in before you can comment on or make changes to this bug.