Le Garbage First en détail

Après avoir fait une rapide présentation du Garbage First Collector je pense qu’il est intéressant de voir en détail son fonctionnement.

Au démarrage de la JVM, la mémoire (la heap) est découpée en une multitude de régions de même taille variant entre 1 et 32 Mo. Chacune des régions aura un rôle déterminé et rentrera en compte en fonction de l’âge des données traitées par le GC. Les données sont copiées d’une ou plusieurs régions vers une autre (dans le sens Eden vers Survivor vers Old).

Ce découpage permet à G1 de faire de la collecte en parallèle sans avoir à suspendre tous les threads de l’application.

Fonctionnement détaillé de G1
Pour rappel, la young generation est constituée des zones Eden et Survivor.

Au départ G1 se comporte comme les autres GC lorsqu’ils analysent la young generation. Les threads de l’application sont suspendus (effet stop the world STW), et G1 analyse en parallèle les zones Eden pleines, pour déplacer les objets encore en vie vers des zones Survivor. Cette opération est très rapide car  la grosse majorité des objets en Java ont une durée de vie très courte. Quand une zone de la mémoire est pleine,  il reste très peu d'élément à déplacer vers de nouvelles zones, et l'essentiel des objets sont à supprimer. A la fin du traitement nous avons une zone marquée comme disponible pour accueillir de nouveaux objets.

L’analyse des zones survivor est aussi très rapide et se base sur le même principe en copiant les données encore vivantes vers la old generation.

Le marquage des données désigne la phase où le GC analyse les objets pour savoir s'ils sont  référencés et depuis quand. Dans le tenured (old generation), la phase de marquage se fait en mode concurrent sans avoir besoin d'interrompre les threads applicatifs. Elle permet de calculer la vitalité des différentes zones de la mémoire. Les zones qui ont peu d’objets encore utilisés, sont placées dans la liste des régions candidates à un nettoyage. La phase de nettoyage se fait en même temps qu’une collecte sur la young generation. Il n’y a plus de séparation nette dans les phases de collecte.

Si vous n’utilisez pas le G1, vous pouvez utiliser le Concurrent Mark and Sweep (CMS). Ce dernier a aussi l’avantage de faire son travail en parallèle de l’application sur le tenured, réduisant les interruptions stop-the-world. Mais il peut toujours provoquer des pauses prolongées. Comme le CMS ne fait pas de compactage des données encore en vie, les zones mémoires à analyser peuvent être très grandes. Pourtant, on pourrait penser que la copie des objets est plus coûteuse. Mais comme G1 se concentre sur les zones qui ont plus beaucoup d’objets en vie il y a très peu de copies et le nettoyage des zones sélectionnées est très rapide.

Les phases entraînant un effet stop-the-world sont

• les phases de marquage de la young, du survivor. 
• les phases de copie et de nettoyage des objets sur chacune des zones

Le marquage des objets de la old generation se fait en mode concurrent avec l’application. Pour limiter les temps de ralentissement lorsque les objets sélectionnés seront nettoyés, vous pouvez jouer sur  le paramètre -XX:MaxGCPauseMillis (objectif de temps de pause accordé à G1). En fonction de ce dernier et des dernières statistiques de fonctionnement, le garbage calcule le nombre de zones de la old generation pouvant être traités lors des pauses. Vous pouvez ainsi maîtriser les ralentissements.

Quelques schémas pour résumer

Le marquage de la old se fait en mode concurrent pour donner un indice de vitalité à chacune des zones

Les étapes ci dessous sont représentées comme si elle se faisait de manière séquentielle. Ce n'est pas le cas et elles sont toutes exécutées en parallèle sur des threads différents. Par contre ces étapes qui nécessitent le nettoyage ou la copie d'objet impose une interruption de l'application (STW)

Cet article fait partie d'une série de trois article sur le Garbage First

• Quelques explications sur le Garbage First Collector
• Le Garbage First Collector en détail
• Les logs du Garbage First