Hi Salvador,
Excuse me for cutting in.
Android has two management mechanism systems of memory optimizer.
The systems are "OOM Killer", and "low memory killer".
The "OOM Killer" is implemented as a Linux management capabilities.
The "low memory killer" is implemented as a management function own Android.
The "low memory killer" has been terminated based on the priority of the
application,
it is more flexible than the "OOM Killer".
See:
http://elinux.org/Android_Kernel_Features#oom_handling
I think that it is important to be flexible.
For example, OEM and carriers can be customized for the application freely.
I think it is good, Firefox OS will have a system of memory optimizer on Gecko.
( but, now I don't have a specific proposal of architecture of it.... )
Thanks,
Yusuke Yamamoto
On 2012/10/31 17:44
Subject:
Salvador de la Puente González wrote ;
Hello Justin, thanks for the clearing the question.
Some other doubts inline.
On 31/10/12 01:14, Justin Lebar wrote:
If we kill the homescreen app, for example, when you return to the
homescreen, we'll re-load it. It's not a great experience for users,
but it is not correct that the phone is useless if we kill the
homescreen app.
I knew it. This is happening on Gaia level, isn't it? And I don't know
if the OOM Killer can actually kill the homescreen but I was talking
about taking this out from Gaia to B2G in some standard way.
Yes, I believe Gaia is re-launching the homescreen app when it's
killed due to memory pressure.
I don't understand what you mean by taking this out from Gaia to B2G
in a standard way.
I mean, to mark the homescreen process with "not-killable" in order to
prevent the OOM killer to kill it. This mark can be set to homescreen or
any other process.
Instead, we will
focus on keeping "active" apps (such as the currently visible app; the
hypothetical OOP keyboard, if it's currently shown; and the app
handling an active call) from being killed.
Yes, and how will you distinguish between these active ones and others
not active?
* Foreground apps are active.
* We may need some special cases like "the dialer is active if you're
on a call".
* Then the only part which remains is to identify apps that aren't
foreground but are still doing something the user can observe. A
music player app is the prototypical example.
For this case and the dialer one, how will you distinguish these
observable applications?
We had a long discussion about this some time ago, and I believe that
once Kan-Ru explained what the CPU wake lock actually does (instead of
what cjones and I imagined it did), we concluded that any
"not-foreground, observable" app would need to hold the CPU wake lock,
so we could use that here.
Sorry, I don't understand how the wakelock fits in the figure.
I agree with you that if you are able to distinguish active
(non-background or observable) applications you have a really good
criteria for killing applications. But, anyway, there is something yet
unresolved: suppose the dialer. How can we ensure this application is
never killed?
There are some kinds of applications that, somewhat, claim "please don't
kill me because I will be automatically reopenend and it's more loosely
to close and reopen me than just to keep me alive".
Thanks.
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra
política de envío y recepción de correo electrónico en el enlace situado más
abajo.
This message is intended exclusively for its addressee. We only send and receive
email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
--
-----------------------------------
Yusuke YAMAMOTO
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
