Si les compilateurs à la volée (JIT) sont rapides, la compilation AOT vise à résoudre certains problèmes comme le fait que le temps de « warm up » du JIT peut être beaucoup plus long pour les grandes applications. « Il est également possible que des méthodes Java rarement utilisées ne soient jamais compilées du tout, ce qui peut potentiellement affecter les performances en raison d'invocations interprétées de façon répétée », a expliqué Vladimir Kozlov dans une proposition d’amélioration pour le JDK (JEP).
Cette proposition d’amélioration visant à apporter la compilation AOT a été acceptée dans le projet OpenJDK et sera implémentée dans la prochaine version du JDK, attendue en juillet 2017. Les objectifs sont d’améliorer le temps de démarrage à la fois des petites et grandes applications Java, avec au plus un impact limité sur les performances, tout en changeant le flux de travail de l'utilisateur final aussi peu que possible.
Dans le JEP 295, il est précisé que « pour la version initiale [de la compilation AOT], le seul module pris en charge est java.base. Ceci est fait pour limiter le périmètre de problèmes, puisque le code Java dans java.base est bien connu à l'avance et peut être soigneusement testé en interne. La compilation AOT de tout autre module JDK, ou du code utilisateur, est expérimentale. » La compilation AOT sera faite par un nouvel outil baptisé jaotc, un compilateur java statique qui produit du code natif pour les méthodes java compilées.
« Pour utiliser le module java.base AOT, l'utilisateur devra compiler le module et copier la bibliothèque AOT résultante dans le répertoire d'installation de JDK, ou le spécifier sur la ligne de commande java. L'utilisation du code AOT-compilé est par ailleurs totalement transparente pour les utilisateurs finaux », est-il également indiqué dans le JEP.
Étant donné qu’il s’agit d’un début d’implémentation, il faut aussi noter que la compilation AOT dans le JDK 9 aura certaines limitations à prendre en compte :
- la version initiale de la compilation AOT dans le JDK 9 n'est prise en charge que sur des systèmes Linux 64 bits exécutant Java 64 bits ;
- le système doit avoir installé libelf pour permettre la génération de bibliothèques AOT partagées (.so) à la suite de la compilation AOT ;
- la compilation AOT doit être exécutée sur le même système ou sur un système avec la même configuration que celui sur lequel le code AOT sera utilisé par l'application Java ;
- pour la version initiale dans le JDK 9, le seul module pris en charge pour la compilation AOT sera java.base ;
- seuls G1 et Parallel GC sont pris en charge pour le moment ;
- il peut ne pas être possible de compiler le code Java qui utilise des classes générées dynamiquement et du bytecode (expressions lambda, invoke dynamic) ;
- la même configuration de runtime Java doit être utilisée lors de la compilation AOT et de l'exécution. Par exemple, l'outil jaotc doit être exécuté avec Parallel GC si une application va également utiliser Parallel GC avec le code AOT.
Ces différentes limitations seront progressivement traitées dans les versions suivantes du JDK.
Source : OpenJDK
Et vous ?
Que pensez-vous de la prise en charge de la compilation AOT dans le JDK ?
Voir aussi :
JDK 9 : la nouvelle date de sortie est fixée au 27 juillet 2017, après acceptation de la demande de report de Mark Reinhold
JavaOne 2016 : Oracle veut moderniser Java EE 8 pour le cloud et repousse sa sortie à fin 2017, Java EE 9 devrait être disponible un an plus tard
NetBeans en voie de devenir un projet de la fondation Apache, le projet vient d'être accepté dans Apache Incubator