Garbage Collectors Algorithms
Les garbage collectors ont typiquement les objectifs suivants (plus facile à dire qu’à faire)
- Très courts « stop the world pauses » avec un objectif de quelques millisecondes
- Les temps de pause n’augmentent pas avec un tas, live-set, ou root-set size
- Pour gérer des tailles de tas allant de quelques Mo à plusieurs To
- Haute concurrence – Tout le travail de levage lourd est effectué pendant que les threads Java continuent à s’exécuter
- Haut débit
- Facile à régler
.
Collecteurs d’ordures
Les données dans le tas sont partitionnées en plusieurs régions d’allocation (ou générations) qui sont maintenues séparées en fonction de l’âge de l’objet (i.c’est-à-dire le nombre d’itérations GC survivantes). Alors que certains collecteurs sont uni-générationnels, les autres utilisent deux générations : (1) la jeune génération (encore divisée en Eden et deux régions de survivants) et (2) l’ancienne (ou titulaire) génération.
Source : Blog de Ionut Balosin
Les collecteurs à deux générations:
GC série – Cet algorithme utilise un seul thread pour effectuer tout le travail de collecte des ordures, ce qui le rend relativement efficace car il n’y a pas de surcharge de communication entre les threads. Il est mieux adapté aux machines à un seul processeur car il ne peut pas tirer parti du matériel multiprocesseur.
GC à débit (parallèle) – Cet algorithme utilise mark-copy dans la jeune génération et mark-sweep-compact dans la vieille génération. Les deux collecteurs Young et Old déclenchent des événements stop-the-world, arrêtant tous les threads de l’application pour effectuer le garbage collection. Les deux collecteurs exécutent les phases de marquage et de copie/compactage en utilisant plusieurs threads, d’où le nom de ‘Parallel’.
Parallel Garbage Collector est adapté aux machines multi-cœurs dans les cas où votre objectif principal est d’augmenter le débit. Un débit plus élevé est obtenu grâce à l’utilisation plus efficace des ressources du système :
- pendant la collecte, tous les cœurs nettoient les ordures en parallèle, ce qui entraîne des pauses plus courtes
- entre les cycles de collecte des ordures, aucun des collecteurs ne consomme de ressources
Garbage First (G1) GC – Ce collecteur est un collecteur d’ordures de style serveur, ciblé pour les machines multiprocesseurs avec de grandes mémoires. Il répond aux objectifs de temps de pause de la collecte des ordures (GC) avec une forte probabilité, tout en atteignant un débit élevé.
- Le collecteur G1 adopte une approche différente en termes de modèle de mémoire de tas. Le tas est partitionné en un ensemble de régions de tas de taille égale, chacune étant une plage contiguë de mémoire virtuelle.
- Certains ensembles de régions se voient attribuer les mêmes rôles (eden, survivant, vieux) que dans les anciens collecteurs, mais il n’y a pas de taille fixe pour eux.
- La taille des régions est choisie par la JVM au démarrage. La JVM cible généralement environ 2000 régions dont la taille varie de 1 à 32Mo. Le collecteur G1 adopte une approche différente
Pour plus de détails, consultez le document Getting Started with the G1 GC
Collecteurs non générationnels :
Shenandoah GC – Shenandoah est le collecteur d’ordures à faible temps de pause qui réduit les temps de pause GC en effectuant plus de travail de collecte d’ordures simultanément avec le programme Java en cours d’exécution. Shenandoah effectue la majeure partie du travail GC de manière concurrente, y compris la compaction concurrente, ce qui signifie que ses temps de pause ne sont plus directement proportionnels à la taille du tas. La collecte d’ordures d’un tas de 200 Go ou d’un tas de 2 Go devrait avoir un comportement de pause faible similaire.
Pour plus de détails, veuillez vous référer aux détails de l’implémentation dans le Wiki
Z GC – ZGC est un collecteur de compactage concurrent, à génération unique, basé sur les régions et sensible au NUMA. Les phases d’arrêt du monde sont limitées au balayage de la racine, de sorte que les temps de pause du GC n’augmentent pas avec la taille du tas ou de l’ensemble vivant.
Pour plus de détails, veuillez vous référer à la session sur ZGC par Per Liden sur YouTube
Finalement,
Epsilon GC (expérimental)- Un GC qui gère l’allocation de mémoire mais n’implémente aucun mécanisme réel de récupération de mémoire. Une fois que le tas Java disponible est épuisé, la JVM s’arrête. Conçu pour les tests internes de JDK, mais peut concevablement être utile dans deux situations
- Programmes à très courte durée de vie
- Les programmes sont soigneusement écrits pour réutiliser la mémoire et ne jamais effectuer de nouvelles allocations
.