La vue "Dominants" est une des nouveautés de Firefox 46.
À partir de Firefox 46, l'outil Mémoire inclut une nouvelle vue nommée "Dominants". Celle-ci est utile pour comprendre la "Taille retenue" des objets d'un site : il s'agit de la taille des objets eux-mêmes ainsi que la taille des objets qu'ils gardent en vie par référence.
Si vous n'êtes pas familier avec la "taille de l'objet", la "taille retenue" et les Dominants, il est recommandé de lire l'article sur les concepts des Dominants.
Pour afficher la vue des Dominants, il faut sélectionner "Dominants" dans le menu déroulant "Afficher" :
Cette vue est constituée de deux panneaux:
Ce panneau affiche les objets de la capture qui retiennent le plus de mémoire.
Dans la partie principale de l'UI, la première ligne est nommée "Racines GC". En dessous de cette ligne, il y a une ligne pour :
Pour chacune de ces lignes, seront affichés :
Les lignes sont classées par la taille de mémoire retenue. Par exemple :
Dans cette capture d'écran, il est possible de voir qu'il y a cinq linges en dessus de "GC roots". Les deux premiers objets sont "Call" et "Window", et retiennent respectivement 21% et 8% de la mémoire totale de la capture. Il est également possible de voir qu'ils ont une taille (shallow) réduite, donc quasiment toute la mémoire retenue vient d'objets qu'ils dominent.
Juste en dessous de chaque racine GC, tout les noeuds pour lequel cette racine est le dominant immédiat sont affichés et triés par taille retenue.
Par exemple, cliquer sur le premier objet "Window" affichera ceci :
Il est possible de voir que "Window" domine un objet "CSS2Properties", dont la taille retenue est de 2ù de la capture. Encore une fois, la taille de l'objet est faible, quasiment toute sa taille retenue est due aux objets dominés. En cliquant sur l'icone en fore de triangle à coté de la fonction, il est possible de voir ces noeuds.
Il est ainsi possible de se faire rapidement une idée de quels objets retiennent le plus de mémoire dans la capture.
Il est possible d'utiliser Alt + clic pour étendre le graph entier d'un noeud.
Dans la barre d'outils, il y a une liste déroulante : "Nommer selon" :
Par défaut, l'option sélectionnée est "Type". Il est possible de choisir "Call Stack" à la place pour savoir exactement d'ou dans le code les objets sont alloués.
Cette option est appelée "Allocation Stack" dans Firefox 46.
Pour l'activer, il faut cocher la case "Enregistrer les piles d'allocations" avant de lancer le coder qui alloue les objets. Il faut ensuite prendre une capture, puis sélectionner "Call Stack" dans le menu déroulant "Nommer selon".
Maintenant, le nom du noeud contient le nom de la fonction qui l'a alloué, ainsi que le fichier, la ligne et la position exacte d'ou dans la fonction l'allocation a été faite. Cliquer sur le nom du fichier ouvrira cette position dans le Débogueur.
{{EmbedYouTube("qTF5wCSD124")}}
Parfois, une ligne nommée "(no stack available)" est présente. Les piles d'allocations ne sont actuellement enregistrées que pour les objets, pas pour les tableaux, les strings ou les structures internes.
Ce panneau affiche, pour un noeud sélectionné les 5 plus courts chemins depuis ce noeud jusqu'a une racine GC. Cela permet de voir tous les noeuds qui empêchent ce noeud d'être détruit par le garbage collector (ramasse-miette en bon français). Si un objet est soupçonné de cause une fuite mémoire, ce panneau affichera les objets qui réfrènent l'objet soupçonné.
Pour voir le chemin de rétention, il suffit de sélectionner un noeud dans le panneau de l'arbre des Dominants :
Ici, un objet a été sélectionné et l'on peut voir un unique chemin jusqu'a la racine GC.
La racine GC Window contient une référence à un objet HTMLDivElement. Cet objet contient lui une référence à un Object, et ainsi de suite. Il est possible de retracer le chemin juste en regardant le panneau de l'arbre des Dominants. Si une seule de ces références venait à être supprimée, les objets en dessous seraient détruits par le garbage collector.
Chaque connexion dans le graph est annoté avec le nom de la variable qui référence l'objet.
Parfois, il y a plus d'un seul chemin de rétention :
Ici, il y a deux chemins depuis le noeud DocumentPrototype vers la racine GC. Si seulement l'un des des deux venait à être supprimé, le noeud ne serait pas détruit par le garbage collector, puisqu'il serait toujours retenu par l'autre chemin.
Pour tester l'outil, il est plus simple d'utiliser un exemple
Nous utiliserons l'exemple d'allocation de monstres. Cet exemple crée trois tableaux chacun contenant 5000 monstres, chaque monstre possède un nom généré aléatoirement.
Pour voir à quoi cela ressemble avec la vue "Dominants", il faut :
{{EmbedYouTube("HiWnfMoMs2c")}}
Les trois tableaux seront les trois premières racines GC, chacun retenant à peu près 23% de la mémoire totale de la capture :
Étendre un tableau affichera les objets (monstres) qu'il contient. Chaque monstre à une taille réduite de 160 octets. Cette taille inclut les variables int "eye" et "tentacle-count". Chaque monstre à une taille retenue plus grande, car ils retiennent la string utilisée pour stocker le nom du monstre :
Tout cela se rapproche précisément du graph mémoire attendu. Une chose curieuse cependant, où est passé l'objet qui contient ces trois tableaux ? En regardant le chemin de rétention pour un des tableaux, il est possible de le voir :
Ici, il est possible de voir l'objet retenant le tableau; et même qu'il s'agit du tableau de monstres friendly. Dans la capture d'écran ci-dessus, ce n'est pas visible, cependant ce tableau est aussi enraciné directement à la racine GC. Donc si l'objet arrête de référencer le tableau, celui-ci ne serait toujours pas éligible au garbage collector.
Cela veut dire que l'objet ne domine pas le tableau et donc n'est pas affiché dans l'arbre des Dominants. À voir également, l'article sur le concept des Dominants.
Enfin, il est possible de passer à la vue "Call Stack", afin de voir quels objets sont alloués et de se rendre à ce point dans le Débogueur :
{{EmbedYouTube("qTF5wCSD124")}}