Compromis des images natives

L'image native est puissante, mais elle n'est pas gratuite. Elle échange l'adaptabilité à l'exécution de la JVM contre un démarrage rapide et une faible consommation mémoire. Comprendre ces compromis vous aide à décider quand la compilation native est le bon choix.

Il s'agit du principal avantage. Un binaire natif évite le chargement des classes, la vérification du bytecode et la phase de chauffe de la compilation à la volée. Il peut démarrer en quelques millisecondes, contre plusieurs centaines pour le lancement d'une JVM — un changement déterminant pour les interfaces en ligne de commande et les fonctions sans serveur.

L’absence de compilateur à la volée et de structures de profilage, ainsi qu’un tas d’image précalculé, permettent à un processus natif d’utiliser beaucoup moins de RAM. Vous pouvez ainsi placer davantage d’instances dans chaque conteneur et réduire fortement la capacité à la baisse.

Le compromis essentiel. Le compilateur à la volée optimise son code à partir de profils d’exécution actifs ; une JVM qui fonctionne longtemps peut donc atteindre un débit maximal supérieur à celui d’un fichier binaire AOT optimisé à l’aveugle lors de la construction. Pour les charges de travail soutenues et fortement sollicitées, la JVM peut encore être la meilleure option.

GraalVM réduit l’écart de débit grâce à la PGO : construisez une image instrumentée, exécutez une charge de travail représentative pour recueillir des profils, puis reconstruisez l’image à partir de ces profils. Le fichier binaire AOT ressemble alors à un compilateur à la volée arrivé à maturité pour cette charge de travail.

La construction d’une image native est lente et exige beaucoup de mémoire : plusieurs minutes de CPU et plusieurs gigaoctets de RAM pour les grandes applications. Cela allonge les chaînes d’intégration continue par rapport à une construction rapide avec jar.

La réflexion, les mandataires et les ressources nécessitent des métadonnées, comme expliqué précédemment. Le code qui dépend fortement du chargement de classes à l’exécution ou de la génération de bytecode peut être difficile, voire impossible, à rendre entièrement natif sans modifications.

Certains outils de la JVM fonctionnent différemment en mode natif. Les agents JVMTI standard et certains profileurs ne se connectent pas de la même manière ; vous utilisez à la place une surveillance ou un échantillonnage propres à l’image native. Planifiez votre stratégie d’observabilité en conséquence.

Une image native fournit ses propres collecteurs de mémoire : un collecteur Serial simple et G1 dans certaines éditions. Pour les très grands tas, l’ensemble complet des collecteurs de la JVM peut offrir une meilleure latence. Choisissez le collecteur en fonction de la taille du tas de votre charge de travail et de vos exigences concernant les pauses.

• Fonctions sans serveur qui peuvent réduire leur capacité jusqu’à zéro.
• Outils CLI où le démarrage est le facteur dominant.
• Microservices dans des conteneurs densément remplis.
• Tâches de traitement par lots de courte durée.

• Services de longue durée où le débit maximal est essentiel et où les performances maximales de la compilation à la volée comptent.
• Applications qui chargent massivement des classes de manière dynamique ou génèrent beaucoup de bytecode.
• Charges de travail qui dépendent d’outils fondés sur JVMTI.

Vérifiez votre compréhension des compromis liés aux images natives.

Vous avez évalué les compromis liés aux images natives :

• Avantages : démarrage en quelques millisecondes et faible empreinte mémoire.
• Coûts : débit maximal potentiellement inférieur, constructions lentes, métadonnées pour les fonctionnalités dynamiques et différences entre les outils.
• La PGO réduit l’écart de débit grâce à des reconstructions guidées par les profils.
• Les images natives conviennent aux outils CLI, aux fonctions sans serveur et aux microservices densément déployés.
• La JVM convient aux applications de longue durée, exigeantes en débit et riches en fonctionnalités dynamiques.