Le projet OpenJDK a propos un nouveau projet (Galahad) pour fusionner certaines parties du code de GraalVM Community Edition dans le kit de dveloppement Java. L’quipe a annonc que l’objectif initial du projet Galahad est de contribuer la dernire version du compilateur juste–temps (JIT) de GraalVM et de l’intgrer comme alternative au compilateur JIT existant de la machine virtuelle HotSpot. Il s’agit du dernier dveloppement d’un effort de longue haleine visant fournir une capacit de compiler les applications Java en code machine avant l’excution du programme.
GraalVM est une machine virtuelle Java (JVM) et un kit de dveloppement Java (JDK) crs par Oracle. Il s’agit d’un environnement d’excution haute performance qui permet d’amliorer les performances et l’efficacit des applications. Ses objectifs comprennent : l’criture d’un compilateur plus rapide et plus facile maintenir, l’amlioration des performances des langages qui s’excute sur la JVM, la rduction des temps de dmarrage des applications, l’intgration du support multilangue dans l’cosystme 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 diffrents langages et d’assurer l’interoprabilit 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 dveloppeurs d’excuter efficacement du code dans plusieurs langages et bibliothques au sein d’une seule et mme application. Le projet OpenJDK veut dsormais tirer parti de ces fonctionnalits et a annonc rcemment 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’excution du programme. premire vue, cela semble quelque peu trange. En effet, l’une des premires choses qu’un nouveau dveloppeur Java apprend est que “le langage de programmation Java ne compile pas en code machine, mais plutt 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’excution dynamique – la JVM – pour l’excution.
Cet environnement d’excution permet des techniques d’excution dynamique, telles que le chargement de classes et la rflexion, qui n’ont pas vraiment d’analogues dans les langages compils en avance sur le temps (AOT). En fait, c’est le point de dpart de tout ce qui fait la puissance de Java, et ce qui l’a rendu si rvolutionnaire lorsqu’il est arriv sur la scne du logiciel, il y a environ 25 ans. Malgr cela, il y a toujours eu un intrt pour la possibilit de compiler directement les programmes Java en code machine et de les excuter de manire autonome sans JVM.
Il y a plusieurs raisons ce dsir : rduire le temps de prchauffage des applications Java pour qu’elles atteignent leurs performances maximales, rduire les besoins en mmoire des applications Java, ou mme simplement un dsir gnral d’viter d’utiliser des ressources pour des sous-systmes d’excution dont une application peut ne pas avoir besoin. Plusieurs projets ont tent de concrtiser cette possibilit. Le plus rcent, et sans doute le plus russi ce jour, est le projet GraalVM. Ce projet n’est pas issu d’OpenJDK, mais d’un projet de recherche d’Oracle Labs. La premire version de production, GraalVM 19.0, est arrive en mai 2019.
Depuis lors, GraalVM fonctionne comme un projet indpendant avec un cycle de publication diffrent et une interaction limite avec OpenJDK. Deux des rares propositions d’amlioration 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 arrives 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 opre 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-mme 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 exprimental bas sur Java dans Java 10. Toutefois, dans Java 17 (publi en septembre 2021), les formes exprimentales des compilateurs AOT et JIT ont t supprimes. Malgr cela, l’interface exprimentale du compilateur JVM au niveau Java (JVMCI) a t conserve, de sorte qu’il reste possible d’utiliser des versions du compilateur Graal construites en externe pour la compilation JIT.
La dernire annonce marquera, si elle se droule comme prvu, 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 apports au projet. Galahad sera gr comme un sous-projet d’OpenJDK et maintiendra un dpt spar qui se basera priodiquement sur le dpt principal. Lorsque les fonctionnalits seront prtes, elles seront migres vers le dpt principal. Il s’agit du mme modle qui a t utilis avec succs par des projets de longue haleine tels que Loom et Lambda. Galahad vise le JDK 20 comme base de rfrence initiale.
Pour l’instant, Galahad se concentre sur la contribution de la dernire version du compilateur JIT de GraalVM et son intgration comme alternative au compilateur C2. Plus tard, la technologie de compilation AOT ncessaire sera ajoute afin de rendre le compilateur JIT Graal disponible instantanment au dmarrage de la JVM. Il convient de noter que toute la base de code de GraalVM ne sera pas engage – seulement les composants JIT et AOT de base, ainsi que l’outil Native Image. Les fonctionnalits propritaires d’Oracle prsentes dans GraalVM Enterprise Edititon ne devraient pas tre donnes 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