UseConcMarkSweepGC est obsolète, quel est son remplacement?
Un programme Java donne cet avertissement, avec JRE 10.0.2:
Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
Quel est le remplacement recommandé pour ce commutateur?
Abandonner la prise en charge du système de gestion de contenu, puis supprimer son code ou, du moins, le séparer plus complètement, réduira la charge de maintenance de la base de code du GC et accélérera les nouveaux développements. Le ramasse-miettes G1 est destiné, à long terme, à remplacer la plupart des utilisations du système de gestion de contenu.
Voici les solutions données dans ce blog , si vous utilisez l’algorithme CMS:
(1). Passer à l'algorithme G1 GC
G1 GC est devenu l'algorithme par défaut du GC depuis Java 9. Vous pouvez donc envisager de déplacer votre application vers cet algorithme. Il peut offrir de meilleures performances que l'algorithme CMS GC. C’est beaucoup plus facile à régler car il existe relativement moins d’arguments. En outre, il fournit des options pour éliminer les chaînes en double de la mémoire. Si vous pouvez éliminer les chaînes en double, cela peut vous aider à réduire l'encombrement de la mémoire.
(2). Passer à l'algorithme Z GC
Z GC est un ramasse-miettes évolutif à faible temps de latence. Son objectif est de garder les temps de pause du GC inférieurs à 10 ms. L'accès anticipé à l'algorithme Z GC est disponible dans Java 11, 12. Donc, si votre application s'exécute sur Java 11, 12. Vous pouvez envisager de passer à l'algorithme Z GC. Notre analyse préliminaire de Z GC montre d’excellents résultats.
(3). Continuer avec le CMS
Pour certaines applications, nous avons vu CMS fournir des résultats spectaculaires auxquels le G1 GC n’a pas égalé, même après de nombreux réglages. Donc, si vous avez exploré deux autres options et convaincu que l'algorithme CMS est le mariage parfait pour votre application au paradis :-), vous pouvez envisager d'utiliser l'algorithme CMS lui-même. Il y a même des arguments qui continuent à garder CMS actif dans cette liste de diffusion OpenJDK JDK9-dev . D'après mon expérience personnelle, les fonctionnalités et les API, obsolètes en Java 1.1, continuent d'exister même en Java 12 (même après 20 ans). Il semble que toutes les API et fonctionnalités obsolètes semblent survivre (et ne jamais mourir). Ainsi, continuer à fonctionner sur le CMS est également une option. Bien sûr, c’est votre appel et les parties prenantes de votre application appellent.