Full GC

Collecte stop-the-world de tout le tas : marquage puis compactage. La collecte la plus lente ; dans une application saine elle est rare ou absente.

Déclencheurs typiques : plus de place pour promouvoir ou allouer après une collecte jeune (Allocation Failure), un appel explicite à System.gc(), le seuil du metaspace, une demande d'inspection ou de dump du tas, un collecteur concurrent qui a pris du retard. Le coût croît avec les données vivantes, puisqu'il faut toutes les marquer et les déplacer : des secondes sur un tas de plusieurs gigaoctets.

Serial et Parallel collectent leur génération ancienne par une collecte complète par conception. G1 utilise une collecte complète parallèle depuis JDK 10, mais elle reste un dernier recours. Le signe d'un problème, ce sont des collectes complètes fréquentes qui récupèrent peu : l'ensemble de données vivantes est proche de la taille du tas, et l'application fuit ou est sous-dimensionnée. Lisez la cause dans la ligne de log, Pause Full (cause), puis le tas après la collecte. GC Doctor liste chaque full GC avec sa cause et son tas avant et après.

Génération ancienne

Là où sont installés les objets qui ont survécu à plusieurs collectes jeunes. Elle est collectée rarement, et plus cher, car l'essentiel de son contenu est vivant.

L'occupation de la génération ancienne juste après chaque collecte ancienne est le meilleur signal d'une fuite ou d'une promotion prématurée. Si elle grimpe sans cesse, l'application retient de plus en plus de données (fuite, cache non borné). Si elle monte par paliers, des données de courte durée sont promues trop tôt, souvent parce que l'espace survivor est trop petit ou que le débit d'allocation est élevé.

Les collecteurs récupèrent la génération ancienne de manières différentes : Serial et Parallel la compactent lors d'une collecte complète stop-the-world ; CMS (supprimé en JDK 14) la balayait en concurrence ; G1 la marque en concurrence puis la récupère par petites étapes avec des collectes mixtes ; ZGC et Shenandoah collectent tout le tas en concurrence.

Débit

La part du temps que l'application passe à travailler utilement plutôt qu'en pauses GC.

Un débit de 99 pour cent signifie une seconde de pauses pour 100 secondes. Le réglage orienté débit (Parallel, grands tas) accepte des pauses plus longues et plus rares. Le réglage orienté latence (ZGC, Shenandoah, G1 avec un objectif de pause bas) accepte un travail plus fréquent et plus court, et dépense plus de CPU dans le collecteur.

GC Doctor calcule le débit à partir des pauses de la plage sélectionnée. Il ignore le travail concurrent, qui consomme du CPU sans arrêter l'application : lisez-le avec la vue CPU.