Go 1.26 a apporté l’une des plus importantes évolutions du runtime ces dernières années: le ramasse-miettes Green Tea est désormais activé par défaut. Dans cet article, nous allons comprendre ce qui a changé, pourquoi cela compte et à quoi s’attendre en pratique.
Qu’est-ce que le GC Green Tea?
Le GC Green Tea est une refonte du ramasse-miettes de Go. Il conserve l’approche mark-sweep du GC précédent, mais change fondamentalement la façon dont les objets sont suivis et scannés.
La différence principale: au lieu d’opérer objet par objet éparpillé sur le heap, le Green Tea agit au niveau des pages de mémoire. Il regroupe les objets en blocs contigus de 8 KiB appelés spans et scanne plusieurs objets en même temps dans le même span.
Comment cela fonctionne en pratique
L’accent est mis sur les petits objets — jusqu’à 512 octets — qui sont les plus courants et les plus coûteux à scanner individuellement.
Lorsque le GC rencontre un objet qui doit être scanné, il ne le fait pas immédiatement. Au lieu de cela, il marque la position de l’objet dans son span et attend d’en accumuler plusieurs dans le même span. Lorsque le span est traité, il scanne tous les objets d’un coup.
Cette approche améliore considérablement la localité du cache: accéder à une mémoire contiguë est bien plus rapide que de sauter entre des adresses dispersées sur le heap.
Répartition du travail entre les cœurs
L’ancien GC utilisait une file globale pour répartir le travail entre goroutines. Cela créait des blocages lorsque plusieurs cœurs tentaient d’accéder à la file en même temps.
Green Tea résout cela avec des files locales par worker. Chaque worker dispose de sa propre file de spans à traiter. Lorsqu’un worker devient inactif, il « vole » des tâches à d’autres workers — un schéma connu sous le nom de work stealing. Cela élimine le goulet d’étranglement central et améliore l’évolutivité avec davantage de cœurs.
Résultats de performance
Les chiffres sont encourageants:
-
10% à 40% de réduction de l’overhead GC dans des programmes réels à forte collecte.
-
Environ 10% supplémentaires sur les plateformes AMD64 modernes, grâce à l’utilisation d’instructions vectorielles (AVX-256 et AVX-512) pour accélérer le balayage des petits objets.
Ce ne sont pas des benchmarks artificiels — ce sont des gains observés en production.
Le compromis: plus de mémoire résidente
Tout n’est pas rose. Des benchmarks initiaux montrent une augmentation de 8% à 15% du RSS (résident Set Size). C’est le coût de la stratégie de balayage par spans: maintenir davantage de métadonnées par page consomme plus de mémoire de base.
Pour la plupart des applications, ce compromis en vaut la peine. Mais si votre cas d’usage exige l’empreinte mémoire la plus faible possible, il convient de surveiller cela.
Comment désactiver
Si vous devez revenir à l’ancien GC, il suffit de compiler avec: GOEXPERIMENT=nogreenteagc go build ./...
Mais la recommandation est d’abord tester avec Green Tea activé — les gains sont réels pour la majorité des scénarios.
Relation avec les autres optimisations de Go 1.26
Green Tea GC complète l’allocation spéculative sur la pile qui était déjà disponible depuis Go 1.25. Alors que l’allocation sur la pile réduit le nombre d’objets qui atteignent le heap, Green Tea améliore l’efficacité de collecte des objets qui finiront inévitablement sur le heap.
Associées, ces deux optimisations s’attaquent au problème de performance du GC sous deux angles: moins de déchets à collecter et une collecte plus rapide des déchets restants.
Conclusion
Le GC Green Tea est le type d’amélioration qui démontre la maturité du runtime Go. Sans changer l’API, sans rompre la compatibilité, l’équipe de Go a livré des gains de performance significatifs qui s’obtiennent simplement en mettant à jour le toolchain.
