Oracle a annoncé son intention de rendre Z Garbage Collector (ZGC) open source. Per Liden, créateur de ZGC chez Oracle et membre du projet Hotspot (et anciennement JRockit) a proposé un nouveau projet dans la communauté OpenJDK pour rendre ZGC open source.
ZGC s'est développé en interne chez Oracle dans le but de fournir un ramasse-miettes à faible latence pour les très gros tas. Les principaux objectifs de conception de ZGC sont :
- Gérer des tas de plusieurs téraoctets.
- Limiter la durée de pause du GC à 10 secondes maximum.
- La diminution du débit applicatif ne devrait pas dépasser 15% par rapport au G1.
Selon Liden, son équipe chez Oracle a jusqu'à présent atteint ou dépassé ces objectifs sur des benchmarks bien connus de l'industrie et a des ambitions fortes pour atteindre ces objectifs pour une grande variété de charges de travail ; mais ces objectifs ne sont pas des exigences strictes pour chaque scénario.
ZGC est un ramasse-miettes concurrent à génération unique. Les phases d'Arrêt-Du-Monde sont limitées à l'analyse de la racine, ce qui signifie que les temps de pause GC n'augmenteront pas avec la taille du tas.
Liden prétend que la conception et la mise en œuvre de ZGC sont déjà raisonnablement stables et matures. ZGC exécute actuellement les tâches de GC suivantes simultanément :
- Marquage
- Traitement des références
- Sélection du jeu de relocalisation
- Relocalisation / Compactage
Selon Liden, un principe de conception de base dans ZGC est l'utilisation de barrières de charge avec des pointeurs d'objets colorés. Cela permet à ZGC d'effectuer des opérations simultanées, telles que la relocalisation d'objets, alors que les processus applicatifs Java sont toujours en cours d'exécution. Un pointeur d'objet coloré contient également des informations utilisées par la barrière de charge pour déterminer si une action doit être effectuée avant d'autoriser le processus Java à utiliser le pointeur.
Liden explique que l'approche des pointeurs colorés offre des propriétés remarquables telles que :
- Possibilité de récupérer et de réutiliser la mémoire pendant la phase de relocalisation/finalisation, avant que les pointeurs pointant dans les régions récupérées/réutilisées aient été corrigés. Cette approche permet de réduire le surcoût global. Cela élimine également le besoin d'implémenter un algorithme de marquage/compactage séparé pour gérer l'intégralité de récupération de mémoire.
- Relativement peu de barrières de GC, qui aident à maintenir un faible surcoût d'exécution. Il facilite également la mise en œuvre, l'optimisation et la maintenance du code de barrière GC dans l'interpréteur et dans le compilateur JIT.
- Les pointeurs de couleur sont actuellement utilisés pour stocker les informations relatives au marquage et à la relocalisation, mais la nature polyvalente du schéma de pointeurs colorés permet de stocker tout type d'information et à la barrière de charge d'agir en fonction de ces informations. Cette approche pourrait être bénéfique pour de futures fonctionnalités.
Selon la proposition sur le forum OpenJDK, une grande partie du travail restant consiste à résoudre les problèmes de latence dans les sous-systèmes de non-collecte dans HotSpot, comme la possibilité de supprimer simultanément les entrées périmées dans la StringTable.
Liden veut que le processus de révision des changements soit plus lâche au début et qu'il soit plus strict au fur et à mesure que le projet approche de l'intégration. Si le projet est approuvé par la communauté OpenJDK, Liden serait le chef de projet et le groupe HotSpot d'Oracle en serait le sponsor.
Les votes étaient attendus pour le 8 novembre 2017 et le projet devrait être accepté, mais aucune annonce officielle n'a encore été faite.