La mémoire en Java

Le GC se base sur des hypothèses (générationnelles)

Bien évidemment une application peut se comporter différemment, mais la très grosse majorité suivent ces hypothèses.

La heap (mémoire totale) va être découpée en différentes zones (générations) qui contiendront des objets d’âges différents. Par exemple pour le Serial Garbage Collector nous avons le découpage suivant

Le GC se lance sur une génération lorsque la zone est remplie. Come nous avons des zones plus petites, le travail sera plus rapide.

Un objet nouvellement créé (via un new) est placé dans la jeune génération et plus précisément dans la sous zone Eden. Lorque cet espace est plein, le GC tente de nettoyer les objets. Cette opération est appelée une collecte mineure (Minor collection) car elle implique un nombre limité d’objets.

Il existe deux zones Survivor, et sur les deux nous en avons toujours au moins une des deux qui reste vide. Quand le GC parcourt tous les objets des zones Eden et Survivor (celle occupée),

Quand le GC doit nettoyer la vieille génération, il lance une collecte majeure sur toute la heap (Major collection). Cette collecte est bien plus coûteuse qu’une collecte mineure de la jeune génération.

Sur mon image les zones virtuelles correspondent aux zones disponibles mais non encore allouées.

Si vous suspectez des problèmes de GC, vous devez savoir ce qu’il fait. Pour activer des logs, vous pouvez ajouter des options comme -verbose:gc lorsque vous lancez votre JVM. Par exemple

Le format est

Par exemple 149M→23M(258M) siginifie que 149M étaient utilisés avant l’exécution du GC et qu’il reste 23M encore utilisé après l’exécution sur une taille de heap de 258M

Pour avoir encore plus de détail vous pouvez utiliser l’option -Xlog:gc*

Pour éviter de polluer vos logs applicatives, vous pouvez réorienter ces logs dans un fichier à part en utilisant l’option -Xlog:gc*:garbage-collection.log

Quand le garbage collector doit analyser la mémoire pour libérer de l’espace, l’application est mise en pause (ce qui peut être génant pour des applications pseudo temps réel). On parle de mode stop-the-world

Définir un temps de pause maximal permet de fixer des limites au garbage collector. On peut se poser la question de comment est calculé ce temps ?

Une moyenne des temps d’exécution est calculée, mais elle pondérée pour que les pauses les plus récentes comptent le plus. Au démarrage votre mémoire est peu remplie et le passé récent est beaucoup plus intéressant.

L’objectif de temps de pause maximum est spécifié en millisecondes avec l’option -XX: MaxGCPauseMillis=<nnn>. Si la moyenne plus la variation du temps de pause est supérieure à l’objectif de temps de pause maximum, alors le GC considère que l’objectif n’est pas atteint.

Le GC ajuste la taille de la heap ainsi que d’autres paramètres pour tenter de maintenir cet objectif de pause maximale.

Si on réduit le temps alloué à la collecte, le garbage collector sera lancé plus souvent, réduisant ainsi le débit global (throughput) de l’application.

Un débit est un ratio entre 2 valeurs. Le débit de l’application (throughput) est calculé en divisant le temps passé à collecter les déchets (Garbage collection overhead) et le temps passé en dehors du GC (temps réservé à l’application).

Comme pour le temps de pause maximal, vous pouvez définir un objectif pour limiter le throughput global -XX: GCTimeRatio=nnn.

Par exemple, si ce ratio est défini à 19, le rapport entre le temps de garbage collection et le temps d’application est de 1 / (1 + 19) soit 1/20eme soit 5% du temps total.

Si l’objectif de débit n’est pas atteint, le garbage peut augmenter la taille de la heap pour que le temps passé dans l’application puisse être plus long.

Le facteur le plus important affectant les performances du GC est la mémoire totale disponible (la heap). Étant donné que les collectes se produisent lorsque les générations se remplissent, le débit est inversement proportionnel à la quantité de mémoire disponible.

Les tailles de heap minimale et maximale que le garbage collector peut utiliser peuvent être définies à l’aide des paramètres

Si la valeur minimale est inférieure à la valeur maximale, tout l’espace réservé n’est pas immédiatement validé par la machine virtuelle. Si vous regardez l’image plus haut décrivant la répartition générationnelle de la mémoire, cet espace non validé correspond aux zones virtuelles.

La machine virtuelle essaye de conserver une proportion d’espace libre définie par les paramètres

Les recommandations faites par Oracle sur cette heap sont les suivantes

Après la mémoire totale disponible, le deuxième facteur le plus influent sur les performances, est la proportion de la heap consacrée à la jeune génération: plus cet espace est grand, moins les collectes mineures sont fréquentes. Mais, si la taille maximale de la heap est limitée, la vieille génération sera moins grande et donc la fréquence des collectes majeures sera plus haute.

Le choix optimal dépend un peu de la nature de l’application. Les paramètres pour jouer sur cette taille sont les suivants

La jeune generation est sous découpée en une zone Eden et deux zones Survivor. L’option

Si ces espaces Survivor sont trop petits, le GC transfert plus vite les objets vers la vieille génération. Si ces espaces sont trop grands, ils sont inutilement vides.

Les recommandations faites par Oracle sur cette jeune génération sont les suivantes

Le G1 découpe la heap en un ensemble de petites zones de même taille. A tout moment, chacune de ces régions peut être vide (gris clair), ou attribuée à une génération particulière (eden, survivor, old). Au fur et à mesure que les demandes de mémoire arrivent, le gestionnaire de mémoire distribue des régions libres. Comme pour les autres GC, les efforts de récupération d’espace se concentrent sur la jeune génération là où il est le plus efficace de le faire, avec parfois bien évidemment des récupérations d’espace dans les anciennes générations.

Lors de la phase de marquage, le G1 va identifié les zones qui contiennent le moins d’objets vivants et les traiter en premier (d’où son nom Garbage First!). A chaque fois qu’il va nettoyer une zone il va la vider et recopier les objets restants dans une nouvelle zone disponible. Cette copie peut être une copie

Ceci permet de limiter la fragmentation et de recompacter les données en mémoire. De plus il ne traite pas toute la mémoire d’un coup, il va procéder en mode incrémental pour respecter ses objectifs de temps de pause quelque soit la taille de la heap.

G1 alterne entre deux phases.

Si la taille d’un objet est supérieure à 50% d’une zone, il est considéré comme gigantesque et alloué directement dans une ou plusieurs zones continues de l’ancienne génération en fonction de la taille. Ces objets ne passent pas par les jeunes générations pour limiter les copies.

Voici les principales options du G1 avec leur valeur par défaut. Quand la valeur est ergonomics, la JVM va ajuster la valeur au cours de l’exécution de l’application en fonction de son comportement. Si vous surchargé cette valeur vous perdrez ce paramètrage dynamique

Nous allons nous attarder sur le G1 qui est le GC par défaut. Dans cette section je me base sur les recommandations faites par Oracle.

G1 est conçu pour être efficace sans qu’il soit nécessaire de spécifier des options supplémentaires. Cependant, il existe des cas où les configurations par défaut peuvent être améliorées. Pour constater les problèmes activer les logs comme indiqué dans le chapitre dédié plus haut.

G1 sépare la heap en différentes régions de taille égale (Eden, Survivor, Old). Un objet ne s’étend généralement pas sur plusieurs régions, à l’exception des grands objets qui ne rentrent pas dans une seule région.

ZGC reprend ce principe mais les régions sont appelées des pages. Elles ne se basent pas sur des hypothèses générationnelles mais sur la taille des objets. Les pages peuvent avoir des tailles différentes (mais toujours un multiple de 2 Mo) :

Quand ZGC essaie de recycler une page, il va recopier les objets toujours en vie dans une nouvelle page. Ce mécanisme évite d’avoir une trop grosse fragmentation de la mémoire.

ZGC a une phase appelée marquage, où le principe est toujours le même, identifier les objets qui ne sont plus utilisés (les objets n’ayant plus de référence).

G1 stocke ces références dans chaque zone dans un ensemble appelé remembered set (RS). Mais le maintien des données à jour dans cet ensemble est très coûteux en temps et nécessite souvent des pauses.

ZGC utilise une approche différente en stockant l’état dans un bit de référence : on parle de coloration de référence (colored pointer). Une partie de la mémoire utilisée pour stocker l’objet est utilisée pour stocker l’état. Voici un bloc mémoire de 64 bits (ZGC n’est pas utilisable sur des architectures 32 bits). Le matériel actuel limite une référence à 48 bits pour les adresses de mémoire virtuelle.

ZGC réserve les 42 premiers bits pour l’adresse réelle de l’objet. Les bits restants sont utilisés pour spécifier des metadata :

Quand on fait de la programmation parallèle, une barrière signifie que tout thread ou processus doit s’arrêter à ce stade et ne peut pas continuer tant que tous les autres threads ou processus n’ont pas atteint cette barrière (c’est un type de méthode de synchronisation).

Une barrière de mémoire est un type d’instruction qui oblige un CPU ou un compilateur à appliquer une contrainte sur les opérations de mémoire émises avant et après l’instruction de barrière (lecture ou écriture).

Cela signifie généralement que les opérations émises avant la barrière sont garanties d’être exécutées avant les opérations émises après la barrière.

ZGC s’appuie sur les barrières de lecture (load barrier) pour la lecture d’une référence dans la heap. En gros quand l’application a besoin d’accéder à un objet (chargement d’une référence), elle déclenche une barrière de lecture, qui suit les étapes suivantes pour renvoyer la référence correcte:

Avec ce mécanisme, nous sommes assurés que chaque fois que nous essayons d’accéder à un objet, nous obtenons la référence la plus récente. L’opération peut diminuer les performances lorsqu’on essaie d’accéder la première fois à un objet déplacé. Mais c’est le prix à payer pour pouvoir réaliser les opérations de déplacement sans stopper l’exécution de l’application.

Un cycle GC est découpé en 2 phases majeures : le marquage et la relocalisation (déplacement des objets encore en vie). Ces phases sont en fait elle même découpées en plusieurs étapes décrites dans les sources du ZGC. Même si la majorité des étapes sont faites en parallèle de l’application, 3 étapes nécessitent encore des pauses

Un cycle GC commence par la phase de marquage, qui marque tous les objets accessibles. À la fin de cette phase, nous savons quels objets sont encore vivants et lesquels sont des déchets. ZGC stocke ces informations si l’objet à l’index donné est fortement accessible et / ou final (pour les objets avec une méthode finalize), dans un ensemble propre à chaque page.

Pendant la phase de marquage, la barrière de lecture dans les threads d’application pousse les références non marquées dans un buffer local au thread. Dès que ce buffer est plein, les threads GC se l’approprient et parcourent de manière récursive tous les objets accessibles. Le marquage dans un thread d’application pousse simplement la référence dans un buffer, les threads GC sont responsables de parcourir le graphe des objets et de mettre à jour les informations.

Une fois le marquage fini, ZGC détermine quelles pages vont être évacuées en fonction de certains critères (comme par exemple, les pages contenant le plus de déchets). Ces pages définissent l’ensemble de relocalisation. Un objet est déplacé par un thread GC ou un thread d’application (voir le chapitre précédent). ZGC crée une table de transfert pour chaque page concernée par une relocalisation. Cette table contient la nouvelle adresse de chaque objet déplacé.

Les threads GC parcourent parcourent les objets de l’ensemble de relocalisation et déplacent tous les objets qui n’ont pas encore été déplacés. Si un thread d’application et un thread GC essaient de déplacer le même objet en même temps, le premier thread à déplacer l’objet l’emporte.

Il existe 2 bits de marquage (Marked0 et Marked1). Après la phase de relocalisation, il se peut qu’il y ait encore des références dans l’ensemble de relocalisation qui n’ont pas été remappées et qui ont donc toujours le bit du dernier cycle de marquage défini. Chaque cycle alterne entre ces 2 bits. Si la nouvelle phase de marquage utilise le même bit de marquage, la barrière de lecture détecte cette référence comme déjà marquée

Voici les options principales

Shenandoah découpe la heap en différentes régions de même taille mais ne reprend pas les générations (jeune ou vieille).

La plupart des phases sont non bloquantes mais il reste des étapes qui nécessite d’arrêter l’application

Les principales options JVM recommandées sont: