Tuning JVM et GC (Garbage collector) : Rappel sur les generational garbage collectors

Question : quelle est la spécificité des GC (Garbage collector) générationnel

La technique employée pour les Garbage collector, depuis la JVM 1.2, est appelée "generational garbage collection" combine ces deux techniques pour tirer le meilleur parti des différents algorithmes du GC.

Ainsi, le heap (tas) est divisé en plusieurs zones basées sur l'âge d'un objet. Les différentes générations sont nettoyées (Garbage collection) séparément en utilisant des algorithmes de collection différents.

La mortalité enfantine des objets

L’idée est basée sur le constat de la mortalité enfantine des objets. La majorité des objets ont une durée de vie très courte "mortalité enfantine". Une étude statistique a montré que 80-98% des objets nouvellement alloués, meurent en quelques million d'instructions. Une autre a montré que 80-98% des objets nouvellement alloués, meurent avant qu'un autre Megabyte a été alloué.

Ce constat a un grand impact sur les algorithmes choisis pour le GC.

Generational collector

Ainsi un GC de type "Generational collector" divise le heap en plusieurs zones (générations).

Le objets sont créés, systématiquement, dans une zone dédiée dite young generation(dédié aux jeunes objets).

Les objets qui répondent à des critères de promotion, tels qu'avoir survécu à un certain nombre de collectes (lire GC), sont alors promus à la zone dédiée aux générations plus anciennes.

Cette zone est dite older generation (ou Tenured).

Un "generational collector" est libre d'employer une stratégie différente de collecte pour ses différentes zones et d'exécuter la collecte des "garbage" sur les générations séparément.

Dans la suite, nous utilisons les termes « anglais » afin de faciliter le lien avec les paramètres.

Le tuning de la JVM est le choix des paramètres

La JVM présente quelques dizaines de paramètres, permettant le tuning des performances.

Le plus important est de se fixer des objectifs et de conaitre sa cible.

Voici, quelques éléments à considérer, lors des choix des paramètres de chacune des zones mémoire constituant le Heap :

• Durée de Pause : Est ce que le collecteur arrête le programme pour réaliser la collecte (dit stop-the-world)? Pour combien de temps? Est ce que la durée des pauses peut être limitée ?

• Prédictibilité des pauses : Est ce les pauses causées par le GC peuvent être programmées à des périodes convenables à l'utilisateur du programme et non lorsque le GC le décide?

• Usage CPU : Quel pourcentage de la CPU est consommé par le GC?

• Utilisation de la Mémoire : Certains GC nécessite l'usage d'espace mémoire non accessible par l'utilisateur du programme, ce qui augmente la taille totale de la mémoire utilisée. La taille utilisée est supérieur à la mémoire nécessaire réellement au programme.

• Interaction avec la mémoire virtuelle : Pour les systèmes qui n'ont pas beaucoup de mémoire physique, une opération de GC peut nécessiter une interaction avec la mémoire virtuelle ce qui dégrade les performances.

• Interaction avec le Cache : Même pour les applications dont le heap peut résider dans la mémoire le GC aura comme impact de "flasher" les données utilisées par le programme, à cet instant, en dehors du cache, ce qui dégrade les performances

Suite de l’article sur les paramètres de la JVM, permettant le tuning des performances, dans les prochains postes ….