Le Projet Leyden Retarde Le Compilateur OpenJDK AOT Et Optimise Le Compilateur JIT À La Place

L'objectif du projet Leyden est de "résoudre les problèmes à long terme du temps de démarrage lent de Java, du temps lent pour atteindre les performances maximales et de la grande empreinte mémoire". Il voulait y arriver "en introduisant un concept d'images statiques" dans OpenJDK. Les images statiques résultent de la compilation anticipée (AOT) vers des exécutables natifs. Après deux ans sans activité visible publiquement, le projet Leyden a pivoté en mai 2022 pour optimiser d'abord la compilation Just-in-Time (JIT). Les "optimisations qui en résulteront seront certainement plus faibles" que prévu initialement, et atteindre les développeurs Java grand public fin 2025 au plus tôt. Le projet Graal d'Oracle a déjà atteint l'objectif du projet Leyden, mais à un coût que le projet veut éviter pour l'instant.

Le projet Graal provient d'Oracle Labs et ne fait pas partie d'OpenJDK. Son GraalVM Native Image est un compilateur Java AOT qui produit aujourd'hui des exécutables natifs. Ils ont quatre avantages par rapport au compilateur JIT de Java : démarrage rapide, utilisation réduite de la mémoire et du processeur, moins de vulnérabilités de sécurité et des fichiers de plus petite taille.

Mais ces réalisations ont un coût : GraalVM Native Image applique une hypothèse dite de monde fermé (closed-world) sur les applications Java qui élimine toute une catégorie d'applications Java. Pourquoi ? Parce que Java est un langage dynamique et donne aux applications beaucoup de puissance lors de l'exécution, comme les réflexions, le chargement de classes ou même la construction de classes. Et certaines de ces fonctionnalités ne fonctionnent pas dans le monde fermé de GraalVM Native Image. C'est pourquoi le projet Leyden veut maintenant "explorer un éventail de contraintes, plus faibles que la contrainte du monde fermé, et découvrir quelles optimisations elles permettent". Pourtant, Leyden "produira probablement [...] des images entièrement statiques", mais seulement "à long terme".

OpenJDK a déjà essayé la compilation AOT

Le projet Leyden est la deuxième tentative de compilation AOT d'OpenJDK. Le premier effort était jaotc avec la JEP 295, Ahead-of-Time Compilation, livré dans JDK 9 en septembre 2017. Comme GraalVM Native Image, il utilisait le projet Graal. Contrairement à GraalVM Native Image, il était très impopulaire : lorsqu'Oracle a supprimé jaotc de ses builds de Java 16, "personne ne s'est plaint", a noté sèchement Oracle avec la JEP 410, Remove the Experimental AOT and JIT Compiler, livrée dans le JDK 17.

Le projet Leyden a eu une histoire inhabituelle pour un projet d'OpenJDK. L'architecte du langage Java Mark Reinhold l'a proposé en avril 2020, suivi par OpenJDK l'ayant approuvé en tant que projet en juin 2020. Mais le projet n'avait montré aucun progrès visible au cours des deux années entre cette approbation et la création de sa liste de diffusion en mai 2022. C'est pourquoi le projet ne fait que commencer, se concentrant "plus sur les concepts que sur le code" à présent. Mark Reinhold a déclaré que des composants tels que "la JVM HotSpot, le compilateur C2, le partage de données de classe d'application (class-data sharing ou CDS) et l'outil de liaison jlink" sont des cibles d'optimisation. Il manquait notamment à cette liste CRaC, un projet d'OpenJDK qui réduit le temps de démarrage en chargeant l'état de l'application Java à partir du disque.

Un calcul au dos de l'enveloppe indique les dates de livraison possibles. Les versions LTS ont désormais une importance démesurée en Java. Ben Evans, anciennement de la société de monitoring New Relic, a annoncé à Devoxx UK 2022 qu' "aucune version non-LTS n'a jamais dépassé 1 % de part de marché". Cela montre que les développeurs Java traditionnels ne migrent que d'une version de Java LTS vers une autre version LTS.

Étant donné que le projet Leyden n'est que maintenant en cours, peu de résultats seront prêts pour la production en septembre 2023 pour le JDK 21, la prochaine version LTS. Ainsi, les développeurs Java traditionnels ne verront probablement que les premiers résultats du projet Leyden avec la version LTS après cela, le JDK 25, en septembre 2025. Sur la base de cette hypothèse, le projet Leyden fournirait, au plus tôt, une compilation AOT aux exécutables natifs avec le JDK 29 en septembre 2027. InfoQ continuera à suivre les progrès du projet Leyden.

Spring Boot réagit au projet Leyden

Au moins certaines des fonctionnalités envisagées pour le projet Leyden, telles que jlink ou CRaC, nécessitent une prise en charge du framework d'application pour fonctionner au mieux. C'est pourquoi InfoQ a contacté les développeurs représentant Spring Boot, Quarkus et Micronaut pour leur première réaction à l'annonce du projet Leyden.

Le responsable du projet Spring Framework, Juergen Hoeller, approuve le projet Leyden :

Le projet Leyden est une initiative prometteuse alignée sur la direction générale que nous prenons dans Spring Framework 6 et Spring Boot 3.

Juergen Hoeller adopte également le CRaC pour Spring :

Les snapshots de heap CRAC pourraient devenir une option courante pour améliorer le temps de démarrage des applications basées sur Spring. En prenant l'instantané à la toute fin de la phase de démarrage de l'application, il n'y aurait pratiquement plus de fichiers ouverts ou de ressources réseau à ce stade, conformément aux attentes du CRaC. Spring réinitialise même déjà ses caches communs à la fin d'une actualisation du contexte d'application, effaçant les métadonnées liées au démarrage avant de repeupler dynamiquement les caches avec les métadonnées liées à la requête. En termes de [...] contexte d'application réagissant spécifiquement à un événement d'instantané ou améliorant la "snapsafety" des composants communs, nous essaierons certainement d'autonomiser les premiers utilisateurs dans la mesure où cela est techniquement possible dans notre gamme Spring Framework 6.x.

Juergen Hoeller pense que Spring prendra bientôt en charge jlink et le Java Platform Module System (JPMS) :

Les jalons actuels de Spring Framework 6.0 n'incluent pas encore de descripteurs de module (module-info). Ceci est sur la feuille de route pour le jalon M6 en septembre, réévaluant la préparation du système de modules de l'écosystème tiers alors que nous passons à notre phase de candidat à la version 6.0. Le projet Leyden transformant potentiellement jlink en un outil plus puissant et polyvalent, nous avons l'intention de nous préparer non seulement pour les capacités actuelles de jlink mais aussi pour son évolution future.

Quarkus réagit au projet Leyden

Le cofondateur et codirecteur de Quarkus, Jason Greene, a commenté le projet Leyden :

Nous sommes ravis de l'objectif du projet Leyden de réviser la spécification du langage Java afin de mieux prendre en charge les images statiques, la compilation native et d'autres technologies telles que les points de contrôle JVM. De plus, nous étions heureux de voir que le monde fermé resterait un objectif probable à long terme pour le projet.

Jason Greene adopte le CRaC pour Quarkus :

Le soutien initial au projet de recherche CRaC a récemment été apporté au projet Quarkus par le responsable du CRaC. Étant donné que Quarkus effectue une optimisation au moment de la construction, quel que soit le type de cible d'exécution, vous constatez toujours des économies considérables lors de l'exécution sur OpenJDK, et pas seulement sur GraalVM. L'ajout d'une approche de point de contrôle, telle que CRaC, en plus d'OpenJDK optimise davantage le temps de démarrage. Il n'apporte pas les mêmes économies de mémoire que les images natives, mais c'est une option future intéressante pour les applications qui préfèrent ou nécessitent une exécution dans la JVM.

Cependant, Jason Greene est plus réticent à propos de jlink et JPMS dans Quarkus :

À ce jour, jlink n'apporte des avantages qu'à la surcharge de stockage d'une application basée sur JVM (la surcharge de mémoire et le temps de démarrage sont essentiellement les mêmes sans elle). Cependant, la pratique courante dans un conteneur ou une application Kubernetes consiste à superposer une image de base JVM standard, ce qui apporte déjà des économies supplémentaires par rapport au passage de toutes les applications à jlink (puisque chacune regroupe leur propre JVM ajustée). Dans le cas d'une image native, les éléments à grain fin de la JVM sont compilés dans l'image, donc jlink n'est pas non plus utile dans ce scénario. De même, avec JPMS, Quarkus a déjà la notion de modularité grâce aux extensions Quarkus, vous permettant de réduire votre jeu de dépendances uniquement à ce dont vous avez besoin. L'approche adoptée par Quarkus est compatible avec le simple classpath plat que la plupart de l'écosystème Java et des outils de construction préfèrent aujourd'hui. Du côté des coûts, passer à un modèle de module JPMS pur comme jlink l'exige (pas d'auto-modules) signifierait un changement radical non seulement pour Quarkus mais aussi pour de nombreuses bibliothèques Quarkus qui s'appuie dessus. Avant d'envisager un changement, nous aimerions voir ces facteurs mieux s'équilibrer.

Micronaut réagit au projet Leyden

Sergio del Amo Caballero, ingénieur logiciel principal chez Object Computing, Inc. (OCI), n'avait aucune déclaration officielle de Micronaut Framework sur le projet Leyden. Mais il a souligné un récent problème GitHub pour ajouter le support CRaC dans Micronaut.

Sergio del Amo Caballero a également partagé un clip YouTube de juillet 2020 mettant en vedette le créateur de Micronaut, Graeme Rocher, commentant JPMS : Micronaut prend en charge JPMS et publie des fichiers d'informations sur les modules, mais doit "équilibrer cela avec la prise en charge de Java 8". JPMS a été ajouté dans Java 9, mais Micronaut 3.5, la version actuelle, fonctionne toujours sur Java 8.

Conclusion

Jusqu'à présent, OpenJDK n'a pas abordé "les points douloureux à long terme du temps de démarrage lent de Java, du temps lent pour atteindre des performances optimales et de la grande empreinte". Tout d'abord, son compilateur AOT jaotc n'a pas réussi à gagner du terrain et a été retiré. Ensuite, le projet Leyden a entrepris de normaliser la compilation native en Java, mais a stagné pendant deux ans.

Maintenant que le projet Leyen s'est tourné vers l'optimisation de la compilation JIT, les choses s'améliorent : Spring et Quarkus adoptent CRaC pour réduire le temps de démarrage. Mais en ce qui concerne les applications Java de petites tailles, seul Micronaut adhère à la suggestion du projet Leyden d'utiliser JPMS. Spring prévoit de prendre en charge JPMS dans la version 6 d'ici la fin de 2022, bien que l'écosystème Spring ne le soit pas. Et Quarkus n'a actuellement pas l'intention d'ajouter JPMS.

Les résultats, sous la forme de JEP, du projet Leyden pourraient atteindre les développeurs Java traditionnels d'ici la fin de 2025 au plus tôt. Donc, au moins jusque-là, la combinaison du compilateur GraalVM Native Image AOT avec un framework comme Quarkus, Micronaut ou le prochain Spring Boot 3 reste la meilleure option pour éviter "le temps de démarrage lent de Java, le temps lent pour atteindre des performances optimales et une grande empreinte."