Gestion de la mémoire dans Firefox OS

Firefox OS fonctionne sur certains appareils sévèrement limités en mémoire, et il est facile pour les applications d'épuiser la mémoire disponible sur de tels systèmes. Quand un processus épuise la mémoire disponible sur le système, le noyau doit "tuer" d'autres processus afin de libérer de la mémoire. Cet article explique comment low memory killer and low memory notifications travaillent - les deux systèmes sur le dispositif qui contrôlent ce processus sont tués pour maintenir le système principale en cours d'exécution quand il est à court de mémoire.

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'utilisateurle 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.

Remarque: Quand une application de fond est tué par le LMK, elle est mise dans le gestionnaire de tâches / à travers des balayages de bord comme une "app zombie": la prochaine fois que vous accédez à cette application, elle sera relancé. Le nombre maximal d'applications qui peuvent être maintenu dans cet état est actuellement de 10.

Remarque: Le processus tué lorsque l'appareil manque de mémoire est pas nécessairement celui qui "a causé" la condition out-of-memory.

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.

Remarque: La plupart des processus enfants s'exécutent avec oom_adj égale à 2 pendant qu'ils sont au premier plan. Les processus enfants à l'arrière-plan s'exécutent avec oom_adj entre 3 et 6 (inclus). Exactement la valeur de oom_adj qu'un processus enfant a alors en arrière-plan dépend d'un certain nombre de facteurs, à savoir que ce soit le lecteur de musique, que ce soit l'application du clavier, etc.

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.

Étiquettes et contributeurs liés au document

 Contributeurs à cette page : jwhitlock, qwincy_p
 Dernière mise à jour par : jwhitlock,