Ramasse-miettes de la JVM : les collecteurs, les valeurs par défaut et les rares indicateurs à régler

Ce que c'est

Le guide de réglage de HotSpot recense quatre collecteurs. Serial utilise un seul thread et convient aux petits jeux de données (le guide indique jusqu'à environ 100 Mo) ou aux machines monoprocesseur. Parallel, aussi appelé collecteur de débit, est générationnel, avec plusieurs threads de GC et des pauses stop-the-world. G1 est majoritairement concurrent, vise avec une forte probabilité un objectif de temps de pause tout en préservant le débit, et est sélectionné par défaut sur la plupart des matériels. ZGC maintient les pauses sous la milliseconde indépendamment de la taille du tas, au prix d'un certain débit ; dans JDK 21, son mode générationnel s'active avec -XX:+UseZGC -XX:+ZGenerational. Le chapitre sur l'ergonomie précise les valeurs par défaut : G1 sur les machines de classe serveur, c'est-à-dire deux processeurs ou plus et une mémoire physique d'au moins 1792 Mo, Serial sinon ; un tas initial de 1/64 et un tas maximal de 1/4 de la mémoire physique ; une compilation étagée avec C1 et C2.

Pourquoi c'est important

En venant de Go ou de .NET, la surprise est de constater à quel point le comportement mémoire de la JVM se décide au démarrage, en fonction du nombre de processeurs visibles et de la mémoire. Un conteneur limité à un seul CPU reçoit le collecteur Serial ; un conteneur de 512 Mo obtient un tas maximal d'environ 128 Mo. L'arbitrage entre temps de pause et débit est réel : le guide décrit un objectif de temps de pause maximal (-XX:MaxGCPauseMillis) et un objectif de débit (-XX:GCTimeRatio), indique que le collecteur ajuste la taille du tas et des générations pour atteindre l'objectif privilégié, et avertit que cela peut rendre les collectes plus fréquentes, voire ne pas permettre d'atteindre l'objectif du tout.

Comment l'appliquer

• Fixer explicitement le tas maximal (-Xmx ou -XX:MaxRAMPercentage ; voir l'article sur le dimensionnement des conteneurs) afin que l'empreinte du processus résulte d'une décision et non du hasard.
• Laisser d'abord la VM choisir le collecteur, comme le recommande le guide. Passer à Parallel lorsque le débit d'un traitement par lots importe et que des pauses stop-the-world plus longues sont acceptables, conserver G1 lorsque le temps de réponse compte, choisir ZGC lorsque les pauses doivent rester sous la milliseconde.
• Activer la journalisation du GC dès le premier jour : -Xlog:gc*:file=/var/log/app/gc.log:time,uptime:filecount=5,filesize=20m. Toute décision de réglage ultérieure de cette liste dépend de ce journal.
• Ne fixer un objectif de pause qu'après lecture des journaux, et mesurer le coût en débit.
• Tester tout changement d'indicateur sous charge, avec redémarrage, avant qu'il n'arrive en production ; l'ergonomie diffère entre un portable et un conteneur.

Pièges

Copier des jeux d'indicateurs issus de documents écrits pour JDK 8 : la JEP 363 a supprimé le collecteur CMS dans JDK 14 et précise que -XX:+UseConcMarkSweepGC est alors ignoré, avec un avertissement, tandis que la JVM continue avec le collecteur par défaut. Fixer un tas plus grand que ce que le conteneur autorise. Régler manuellement la taille des jeunes et vieilles générations avant que les journaux ne montrent un problème. Interpréter un GC complet comme une fuite mémoire sans histogramme ni dump du tas.