Le projet OpenJDK a proposé un nouveau projet (Galahad) pour fusionner certaines parties du code de GraalVM Community Edition dans le kit de développement Java. L'équipe a annoncé que l'objectif initial du projet Galahad est de contribuer à la dernière version du compilateur juste-à-temps (JIT) de GraalVM et de l'intégrer comme alternative au compilateur JIT existant de la machine virtuelle HotSpot. Il s'agit du dernier développement d'un effort de longue haleine visant à fournir une capacité de compiler les applications Java en code machine avant l'exécution du programme.GraalVM est une machine virtuelle Java (JVM) et un kit de développement Java (JDK) créés par Oracle. Il s'agit d'un environnement d'exécution haute performance qui permet d'améliorer les performances et l'efficacité des applications. Ses objectifs comprennent : l'écriture d'un compilateur plus rapide et plus facile à maintenir, l'amélioration des performances des langages qui s'exécute sur la JVM, la réduction des temps de démarrage des applications, l'intégration du support multilangue dans l'écosystème Java, ainsi que la fourniture d'un ensemble d'outils de programmation pour ce faire. GraalVM ajoute un compilateur optimisant au JDK.
Ce qui permet d'optimiser les performances des différents langages et d'assurer l'interopérabilité des applications polyglottes. Outre la prise en charge du code Java, GraalVM prend également en charge d'autres langages de programmation, notamment Scala, Kotlin, Groovy, Clojure, R, Python, JavaScript et Ruby. Essentiellement, il permet aux développeurs d'exécuter efficacement du code dans plusieurs langages et bibliothèques au sein d'une seule et même application. Le projet OpenJDK veut désormais tirer parti de ces fonctionnalités et a annoncé récemment une feuille de route qui lui permettra de prendre en charge GraalVM.
La prise en charge de GraalVM vise essentiellement à offrir aux utilisateurs d'OpenJDK la capacité de compiler les applications Java en code machine avant l'exécution du programme. À première vue, cela semble quelque peu étrange. En effet, l'une des premières choses qu'un nouveau développeur Java apprend est que "le langage de programmation Java ne compile pas en code machine, mais plutôt en bytecode JVM". Cette simple maxime a des implications profondes, dont la plus fondamentale est que la plateforme Java s'appuie sur un puissant environnement d'exécution dynamique - la JVM - pour l'exécution.
Cet environnement d'exécution permet des techniques d'exécution dynamique, telles que le chargement de classes et la réflexion, qui n'ont pas vraiment d'analogues dans les langages compilés en avance sur le temps (AOT). En fait, c'est le point de départ de tout ce qui fait la puissance de Java, et ce qui l'a rendu si révolutionnaire lorsqu'il est arrivé sur la scène du logiciel, il y a environ 25 ans. Malgré cela, il y a toujours eu un intérêt pour la possibilité de compiler directement les programmes Java en code machine et de les exécuter de manière autonome sans JVM.
Il y a plusieurs raisons à ce désir : réduire le temps de préchauffage des applications Java pour qu'elles atteignent leurs performances maximales, réduire les besoins en mémoire des applications Java, ou même simplement un désir général d'éviter d'utiliser des ressources pour des sous-systèmes d'exécution dont une application peut ne pas avoir besoin. Plusieurs projets ont tenté de concrétiser cette possibilité. Le plus récent, et sans doute le plus réussi à ce jour, est le projet GraalVM. Ce projet n'est pas issu d'OpenJDK, mais d'un projet de recherche d'Oracle Labs. La première version de production, GraalVM 19.0, est arrivée en mai 2019.
Depuis lors, GraalVM fonctionne comme un projet indépendant avec un cycle de publication différent et une interaction limitée avec OpenJDK. Deux des rares propositions d'amélioration de Java (JEP) qui se rapportent à GraalVM sont : JEP 243 (Java-Level JVM Compiler Interface) et JEP 295 (Ahead-of-Time Compilation). Les deux sont arrivées dans Java 9 et, ensemble, elles ont introduit le compilateur Graal dans la base de code d'OpenJDK. Le compilateur Graal est l'un des principaux composants de GraalVM. C'est un compilateur qui opère sur le bytecode Java et produit du code machine. Il peut fonctionner en mode JIT ou AOT.
Dans le premier cas, il peut être utilisé à la place de C2. Rappelons que Graal est lui-même écrit en Java, contrairement aux autres compilateurs JIT disponibles pour la JVM qui sont écrits en C++. Graal a été mis à disposition en tant que compilateur JIT expérimental basé sur Java dans Java 10. Toutefois, dans Java 17 (publié en septembre 2021), les formes expérimentales des compilateurs AOT et JIT ont été supprimées. Malgré cela, l'interface expérimentale du compilateur JVM au niveau Java (JVMCI) a été conservée, de sorte qu'il reste possible d'utiliser des versions du compilateur Graal construites en externe pour la compilation JIT.
La dernière annonce marquera, si elle se déroule comme prévu, le retour de Graal dans la base de code d'OpenJDK. Cependant, ce qui est peut-être plus significatif, c'est le processus GraalVM et les changements apportés au projet. Galahad sera géré comme un sous-projet d'OpenJDK et maintiendra un dépôt séparé qui se basera périodiquement sur le dépôt principal. Lorsque les fonctionnalités seront prêtes, elles seront migrées vers le dépôt principal. Il s'agit du même modèle qui a été utilisé avec succès par des projets de longue haleine tels que Loom et Lambda. Galahad vise le JDK 20 comme base de référence initiale.
Pour l'instant, Galahad se concentre sur la contribution de la dernière version du compilateur JIT de GraalVM et son intégration comme alternative au compilateur C2. Plus tard, la technologie de compilation AOT nécessaire sera ajoutée afin de rendre le compilateur JIT Graal disponible instantanément au démarrage de la JVM. Il convient de noter que toute la base de code de GraalVM ne sera pas engagée - seulement les composants JIT et AOT de base, ainsi que l'outil Native Image. Les fonctionnalités propriétaires d'Oracle présentes dans GraalVM Enterprise Edititon ne devraient pas être données au projet.
Sources : Le projet Galahad, GraalVM
Et vous ?
Que pensez-vous du projet Galahad ? Quels impacts pourrait-il avoir sur la productivité des utilisateurs d'OpenJDK ?Voir aussi
OpenJDK envisage des traces de pile asynchrones pour Java, elles permettent d'inclure des informations sur les trames de pile Java et natives Développeurs Java : la version d'OpenJDK de Microsoft est désormais disponible et inclut des binaires pour Java 11 basés sur OpenJDK 11.0.11 Le JDK 16 est déjà en cours de développement, bien que les travaux sur le JDK 15 continuent, et devrait arriver avec la prise en charge des fonctionnalités du C++ 14