Pour qu’une application puisse bénéficier des meilleures performances, il lui faut remplir un certain nombre de conditions. Pour aider les développeurs dans cette tâche, il a été mis en œuvre le garbage collector (ramasse-miettes) afin de nettoyer tous les objets non référencés par l’application conçue.
La machine virtuelle Java qui (JVM) qui disposait en son sein de Parallel GC comme ramasse-miettes vient de voir cette fonctionnalité être mise en arrière-plan en faveur de Garbage-First (G1) qui sera le ramasse-miettes par défaut dans la prochaine machine virtuelle de l’environnement de développement Java 9.
L’objectif est de remédier à certaines insuffisances du ramasse-miettes actuel GC. En effet, GC effectue ses opérations de nettoyage en parallèle afin de gagner en performance. L’effet pervers de cette fonctionnalité est que le ramasse-miettes a besoin à des moments donnés d’effectuer des pauses qui peuvent aller jusqu’à quelques secondes afin de nettoyer le heap (tas). Si le temps de pause n’est pas pour vous un souci, alors GC vous conviendra parfaitement. Mais pour d’autres applications ou serveurs, GC n’est pas une solution appropriée.
C’est pour corriger ces problèmes de temps de pause longs que G1 a été mis en œuvre et adopté pour occuper la première place comme ramasse-miettes dans Java 9. Plusieurs avantages lui sont conférés. Par exemple, on lui reconnait un paramétrage qui permet un temps de latence relativement bas.
Cela est assez significatif dans la mesure où certains serveurs traitant des informations en flux continu ne peuvent s’offrir le luxe de temps de pause élevé au risque de payer le prix fort. Le domaine de prédilection pour l’usage de ce collector sera donc les serveurs de configurations 32 et 64 bits.
Toutefois, les changements entrainant généralement des contestations, une polémique n’a eu de cesse d’être alimentée après l’annonce de cette décision. Certains opposant G1 à GC. D’autres préférant CMS comme ramasse-miettes par défaut au lieu de G1.
Pour apaiser les tensions, Kirk Pepperdin, figure de référence dans l’optimisation des performances Java a précisé que G1 n’a pas pour vocation de remplacer le collecteur orienté débit (Parallel[Old]GC). La même consigne s’applique également à CMS GC.
Ceux qui souhaiteront utiliser CMS ou Parallel GC pourront le faire en spécifiant avec des lignes de commande le collector sur lequel ils ont porté leur dévolu. Ceux par contre qui souhaiteront utiliser G1 dans Java 9 n’auront aucune modification à faire.
Oracle souligne par ailleurs que « la modification est basée sur l’hypothèse que la limitation de latence est souvent plus importante que de maximiser le débit. Si cette hypothèse est incorrecte alors ce changement pourrait avoir besoin d’être reconsidéré ». De même, si G1 connait des problèmes critiques qui n’arrivent pas à être résolus à temps, Parallel GC sera le ramasse-miettes par défaut à la sortie de JDK 9.
Source : Oracle
Et vous ?
Avez-vous utilisé G1 ? Qu’en dites-vous ?
Que pensez-vous de ce changement ?
Quel est le ramasse-miettes que vous utilisez pour vos applications ?
Oracle adopte G1 comme ramasse-miettes par défaut,
Pour la prochaine machine virtuelle du JDK 9
Oracle adopte G1 comme ramasse-miettes par défaut,
Pour la prochaine machine virtuelle du JDK 9
Le , par Olivier Famien
Une erreur dans cette actualité ? Signalez-nous-la !