Gestion de la mémoire dans Firefox OS

Une opération Firefox OS implique plusieurs processus - un "processus principal" exécutant des services de base du système, et potentiellement de nombreux "processus enfants". En général chaque application fonctionne dans son propre processus enfant. Parce que dans les applications de l'environnement Firefox OS sont rarement fermée par l'utilisateur,  le système gère automatiquement leur durée de vie pour faire place à de nouvelles applications ou des applications existantes nécessitant de la mémoire supplémentaire.

Deux sous-systèmes sont utilisés pour gérer ceci: le Low memory killer (LMK) et le Low memory notifications.

Low memory killer

Le LMK est un sous-système du noyau Android qui tue automatiquement les processus pour faire place à des demandes de mémoire. Afin de choisir quel processus est tué d'abord pour libérer de la mémoire, chaque processus est assignée une priorité par l'intermédiaire des fichiers /proc/<pid>/oom_adj ou /proc/<pid>/oom_score_adj. La priorité d'un processus est connu comme son score d'ajustement , ou oom_adj.  Les plus petites valeurs de oom_adj correspondent à des processus de priorité supérieure.

En général, plus le score d'ajustement est élévé, plus le processus est susceptible d'être tué. Le LMK offre de multiples niveaux, chacun correspondant à une certaine quantité de mémoire libre et un score d'ajustement minimum. Chaque fois que la quantité de mémoire libre dans le système tombe en dessous d'un certain seuil, tous les processus avec un score d'ajustement plus élevées que le minimum spécifié pour ce niveau sont admissibles à être tué. Le LMK commencera à tuer ces processus, les plus grandes d'abord, et continuera jusqu'à ce qu'il a libéré suffisamment de mémoire pour aller au-dessus de ce seuil.

Les priorités d'un processus

Dans Firefox OS les applications sont tués dans la politique d'ordre de priorité suivant, qui est appliquée en donnant à chaque demande un niveau de priorité et en associant un score d'ajustement OOM à ces niveaux (les valeurs actuelles sont définies dans prefs):

1. Les premières applications à être tués seront les applications d'arrière-plan, en commençant par le moins récemment utilisé.
2. Les applications de fond qui sont perceptibles par l'utilisateur sont tués ensuite (par exemple, un lecteur de musique lecture audio en arrière-plan ou une application tenant une haute priorité ou cpu wakelock et ayant un gestionnaire enregistré pour les messages du système.)
3. Si l'application du clavier est en marche, elle sera tué ensuite.
4. Les applications de premier plan seront tués ensuite.
5. Enfin, les applications de premier plan qui ont demandé à haute priorité ou cpu wakelocks sont les derniers à se faire tuer.

Il ya quelques exceptions à ces règles:

• Le processus principal n'est jamais tué par le LMK car cela tuerait tous les processus de l'enfant et redémarrera le système d'exploitation. Le processus principal fonctionne avec oom_adj 0.
• Nous gardons un processus autour pour accélérer le démarrage de nouvelles applications appelées le processus préallouée. Ce processus est généralement toujours maintenu en vie car il consomme très peu de mémoire et accélère considérablement démarrage de l'application. Le seul cas dans lequel il peut être tué est si il n'y a pas assez de mémoire disponible pour le processus principal pour continuer à fonctionner après avoir tué tous les autres processus.

Low memory notifications

Le second mécanisme que nous utilisons pour libérer de la mémoire est low memory notifications. Le LMK fournit un seuil spécial qui, lorsqu'on les croise, peut envoyer des notifications à l'espace utilisateur qui exécute faible sur la mémoire. La fois l'application du système et des applications régulières d'utilisateurs attendent en permanence pour cette condition et vont réagir sur elle par l'envoi d'un événement mémoire pression par l'intermédiaire du service d'observateur. Cet événement est visible uniquement à code C ++ et JS chrome et non pas directement par une application. Grâce à la base de code Gecko nous utilisons cet événement pour libérer autant de mémoire que nous pouvons - normalement en purgeant les caches internes (images, DNS, sqlite, etc.), l'abandon des actifs qui peuvent être recréées (contexts WebGL par exemple) et l'exécution du garbage collector et collecteur de cycles.

Lorsqu'il rencontre une condition de mémoire faible the premier événement memory-pressure qui sera envoyé aura the low-memory payload. Si après un temps prédéfini (5s) nous sommes toujours dans une condition de mémoire faible un autre événement memory-pressure sera tiré, mais cette fois avec le low-memory-ongoing payload. Ce payload est utilisé lorsque nous continuons à connaître des conditions de mémoire faible et nous voulons vider les caches et faire d'autres formes bon marché de la mémoire minimisation, mais nous savons que les approches main lourde comme un GC est peu probable de réussir.

Comment le LMK et le low memory notifications travaillent ensemble

Actuellement, le seuil de memoire faible est réglé au dessus du niveau de LMK pour les applications en arrière. Donc l'action agrégée de la LMK et du low memory notifications est la suivante lorsqu'un périphérique est à court de mémoire:

1. Tuer des applications d'arrière-plan dans l'ordre least-recently-used.
2. Si nous ne libérons assez de mémoire, envoyez des événements memory-pressure à toutes les applications restantes.
3. Si la condition persiste, renvoyer un événement memory-pressure chaque 5 secondes, mais les marquer comme en cours de sorte que le GC / CC ne réagit pas à eux.
4. Tuer des applications de fond perceptibles ou hautement prioritaires.
5. Tuez l'application du clavier, si elle est en cours d'exécution.
6. Tuer des applications de premier plan.
7. Tuer des applications de premier plan de haute priorité.
8. Tuer le processus préallouée.