Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Le JDK 9 va supporter la compilation anticipée (AOT)
En commençant par les systèmes Linux 64-bit exécutant Java 64-bit

Le , par Michael Guilloux

155PARTAGES

4  0 
Java 9 sera livré avec le support de la compilation anticipée (ou compilation AOT). La compilation anticipée est une compilation qui traduit un langage évolué en langage machine avant l'exécution d'un programme. Elle s’oppose à la compilation à la volée (JIT) qui se fait lors de l'exécution du programme. La compilation AOT va donc permettre de compiler les classes Java en code natif avant de lancer la machine virtuelle.

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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Mickael_Istria
Membre émérite https://www.developpez.com
Le 02/05/2017 à 12:18
Citation Envoyé par Vyrob Voir le message
Y a un truc qui m'échappe : pourquoi se manifestent-ils seulement maintenant, à 3 mois de la release ? Le projet Jigsaw ne date pourtant pas d'hier.
Il faut lire les posts detailles et les discussions en lien.
Les inquietudes vis-a-vis de Jigsaw et de son interet technique et pour la communaute ont ete manifestees par tous des le debut. La compatibilite avec OSGi ou Maven a ete identifiee comme critique tres tot. Maitenant que Jigsaw a atteint un "pallier", il a ete teste dans ces environnements (OSGi et Maven) et il apparait qu'en l'etat actuel, ca complique tout sans ajouter grand chose. En l'etat actuel, il ne delivre pas les promesses qui ont ete identifiees initialement comme des "requirements".
Si l'annonce n'est publiee que maintenant, c'est qu'avant, il y avait encore de l'espoir que ca tourne mieux; mais maintenant, Jigsaw est face a un constat d'echec programme, et il est donc temps d'etre plus explicite si on veut que les choses aillent dans le bon sens.

Le principal avantage sera la taille en mémoire de la JVM qui va considérablement baisser.
Si par memoire tu entends "espace disque du deliverable", OK. Pour la RAM ou le Heap ca ne devrait pas changer grand chose car les classloaders ne chargent deja que ce qui est utile.
5  0 
Avatar de Mickael_Istria
Membre émérite https://www.developpez.com
Le 18/02/2017 à 13:05
Citation Envoyé par Pill_S Voir le message
(byebye OSGi)
C'est a peu pres impossible car:
1. Les applis modulaires qui veulent etre backward-compatible ne pourront pas utiliser Jigsaw et devront utiliser OSGi
2. Jigsaw ne gere pas vraiment de "lifecycle" des modules, ou en tout cas ne laisse pas le developpeur s'appuyer dessus pour gerer son appli (c'est un point tres important en IoT)
3. Jigsaw ne dispose pas d'une couche service comme OSGi
4. OSGi a deja beaucoup d'utilisateurs, notamment des tres difficiles -politiquement parlant- a migrer (comme les use-cases embarques)
5. J'attends de voir si les developpeurs Java "finaux" vont vraiment avoir quelque chose a faire de Jigsaw pour leurs apps. Au final, les applis sont deja quasiment toutes dans des conteneurs modulaires genre OSGi ou Java EE, donc ajouter la modularite a la couche de la JVM ne devrait pas leur changer grand chose.

Les raisons techniques (1,2,3) rendent par exemple entre impossible et inutile la migration d'applis existantes comme Eclipse ou Karaf

Au final, j'imagine que seule les applis neuves visant vraiment les perfs optimales (donc l'embarque) vont rapidement adopter Jigsaw, et encore, il faudra attendre que Java 9 soit considere comme robuste avant qu'ils y passent. Pour le dev Java workstation ou serveur, la valeur de Jigsaw est tres faible et inferieure a OSGi.
2  0 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 10/05/2017 à 7:27
La prédiction n'a jamais été une science exacte, d'une part, et d'autre part la manie d'établir des dates de rendu même quand on n'en sait fichtrement rien n'aide pas à ce qu'elles soient respectées. Dans ces conditions, on a beau faire ce qu'on peut, il ne faut pas s'étonner que ça arrive.
2  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 07/09/2017 à 17:24
Citation Envoyé par Matthieu Vergne Voir le message
Et c'est où qu'il prend en compte ce qui est faisable en interne ? Parce que bon, copier les autres a ses avantages, mais si c'est pour avoir en pratique le même rythme et se contenter de sortir des versions qui sont juste de moins en moins boguées, les utilisateurs resteront au rythme habituel pour éviter de perdre leur temps, en se contentant d'ignorer les versions intermédiaires.
L'intérêt c'est que les versions intermédiaires pourront proposer de nouvelles fonctionnalités plus "simple", sans avoir à dépendre du temps de développement trop important d'une autre fonctionnalités.

Par exemple si cela aurait été le cas on aurait déjà pu avoir le REPL, HttpClient avec support d'HTTP2, l'évolution de la classe Process, etc.

Citation Envoyé par Matthieu Vergne Voir le message
Ce qui veut dire qu'à terme il n'en restera qu'un seul. L'objectif, si on lit entre les lignes, et de supprimer l'un des deux. La question est alors de savoir lequel. Je vous le laisse en mille. Reste à voir ensuite l'évolution que ça engendrera, style pas en arrière sur les licences avec celui qui reste. En surface, ça semble génial, mais où sont les garanties ?
Moi je vois plutôt çà dans le sens où çà leur permettra de proposer plus facilement leur JDK commerciale.

S'ils tuent l'OpenJDK ils se prendront un gros bad-buzz, se retrouveront éjecté des distributions, et risqueraient de voir un fork...

Citation Envoyé par ParseCoder Voir le message
Dommage qu'Oracle n'ai pas choisit une license aussi libérale que la license du .NET Compiler Platform (Roslyn).
C'est à dire ?
On est sur du GPLv2 là je ne vois pas où est le problème...

a++
2  0 
Avatar de kilroyFR
Membre éclairé https://www.developpez.com
Le 07/09/2017 à 20:38
Oracle ne faisant rien sans arriere pensée (il faut bien payer l'ile de l'insatiable ellison), du business, rien que du business dans cette strategie.
2  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 11/09/2017 à 15:11
Citation Envoyé par Matthieu Vergne Voir le message
La position que je prend est plus celle du questionnement : qu'est-ce qui empêcherait Oracle de prendre de telles mesures aux dépends de la communauté ? À l'heure actuelle, je ne vois pas de garantie qui permette de se dire "ça c'est une bonne chose". J'ai l'impression qu'à l'heure actuelle, c'est plus une question de pari/confiance.
On peut toujours ce méfier, mais cette question n'a rien de particulier à la situation. On peut tout a fait la poser pour n'importe quel langage/société. Il n'y a pas plus de raison d'être sceptique qu'envers Microsoft, Google, Apple, Redhat, ...
2  0 
Avatar de yann2
Membre expérimenté https://www.developpez.com
Le 29/10/2016 à 13:12
Citation Envoyé par derderder Voir le message
Plutôt que de tout refaire from scratch, il ferait mieux de réutiliser le code de ART ( Android Runtime, le précompilateur java d'Android) qui marche et est largement testé et utilisé, plutôt que de se lancer dans leur propre implémentation infaisable à faire dans les délais de sortie du JDK...
Si je ne me trompe pas, ART c'est uniquement pour l'OS Android.

Citation Envoyé par Songbird_ Voir le message
Je ne vois plus tellement l'intérêt d'utiliser Java, dans ce cas.
Un des intérêts de Java est effectivement Write once run everywhere. Effectivement, avec cette fonctionnalité ce ne sera plus le cas (mais bon personne nous oblige à faire de la compilation anticipée...). A terme, ils visent certainement le Write once compile everywhere ?! Le write once run everywhere n'est pas du tout le seul intérêt de Java.

Je ne me sens pas vraiment excité par la news, le but est d'éliminer le coût d'évaluation des instructions interprétées mais c'est déjà ce que fait le JIT (ok c'est au runtime mais, ça coûte si cher que ça ? Un serveur, une fois démarré, on n'est pas censé le redémarrer toutes les 20 minutes). En fait, j'ai du mal à voir un use case intéressant pour cette techno (je n'ai pas lu la source) ou alors peut être pour une application pour laquelle on veut des performances aux petits oignons ?!
1  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 29/10/2016 à 21:13
Citation Envoyé par yann2 Voir le message
Je ne me sens pas vraiment excité par la news, le but est d'éliminer le coût d'évaluation des instructions interprétées mais c'est déjà ce que fait le JIT (ok c'est au runtime mais, ça coûte si cher que ça ? Un serveur, une fois démarré, on n'est pas censé le redémarrer toutes les 20 minutes). En fait, j'ai du mal à voir un use case intéressant pour cette techno (je n'ai pas lu la source) ou alors peut être pour une application pour laquelle on veut des performances aux petits oignons ?!
Je pense que l'intérêt se situe plutôt coté client pour accélérer le démarrage des applications, en conservant le code natif au lieu de le recompiler à chaque fois...
Ou alors pour déployer des applications sur des devices spécifiques (TV, etc.)

Citation Envoyé par Songbird_ Voir le message
En revanche, dans le domaine du jeu vidéo, ça pourrait peut-être permettre à Java de commencer à faire ses premiers pas concrets dans ce milieu.
Je pense que le plus gros problème vient plus de l'absence de type "value", qui rend le partage de données difficile entre Java et les appels systèmes natifs...

a++
1  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 30/10/2016 à 18:07
Citation Envoyé par yann2 Voir le message
Ok pour le côté device spécifique mais pour un client lourd j'ai vraiment du mal à voir l'intérêt. Il me semble que le JIT est capable d'optimiser la génération de code machine en analysant la manière dont est utilisée l'application (inline d'une opération souvent appelée par exemple). En générant le code machine au moment de la compilation on perd ces optimisations, non ?
Oui en effet on perdrait certaines optimisations liés au contexte d’exécution.
Mais apparemment le code AOT peut être recompilé par le compilateur JIT.

Donc grosso-modo cela pourrait aussi permettre d'exécuter du code natif au lieu du code interprété, tout en bénéficiant d'une compilation JIT si besoin.

Citation Envoyé par yann2 Voir le message
Ok, ça aurait été sympa d'avoir des exemples ou chiffres. Parce que, chez moi, Java est déjà super rapide, les seules fois où j'ai des problèmes de performance c'est parce que j'ai fait de la merde
Je pense que l'intérêt c'est d'améliorer le temps de démarrage.
Java est très performant pour de "grosses" tâches, mais moins pour un programme qui retourne une valeur immédiatement...

Le fait d'avoir un java.base précompilé devrait aider de ce coté là.

a++
1  0 
Avatar de l'art souille
Membre régulier https://www.developpez.com
Le 02/11/2016 à 23:06
Une excellente étude (IBM) en plusieurs parties sur la compilation real-time Java (notamment Part 2 : JIT et AOT) : http://www.ibm.com/developerworks/vi...time+Java+Part
1  0