Discussion :

[Népomucène]

Cela dit, perso, je ne vois pas en quoi on peut espérer des vrais gains de perf à réécrire le compilo JIT en java.

<TROLL>

Il est intéressant de voir qu'en dépit des 5.245 visites (au moment où je poste) et 19 réponses dont certaines très fouillées,
personne n'arrive à percevoir un avantage net et clair de Graal.

à quoi sert ce projet ?

</TROLL>

[pseudocode]

<TROLL>

Il est intéressant de voir qu'en dépit des 5.245 visites (au moment où je poste) et 19 réponses dont certaines très fouillées,
personne n'arrive à percevoir un avantage net et clair de Graal.

à quoi sert ce projet ?

</TROLL>

Graal est un compilateur JIT, écrit en Java.

Avantages :

1. Il produit un code natif de meilleur qualité que le compilo JIT habituel
2. Il est extensible (on peut y injecter ses propres optimiseurs)
3. Il est dynamique, au sens où il s'adapte au code java qu'il est entrain de compiler (prédictions, patterns, ...)

Inconvénients :

1. C'est écrit en java, c'est donc trollesquement plus lent/couteux que le compilo JIT habituel... Sauf que les devs et Oracle annoncent que ce n'est pas plus long qu'avant. Et puis bon, je veux bien perdre quelques millisecondes à la compil JIT pour avoir un code natif de meilleur qualité et gagner des secondes a l'execution.

[Robin56]

Et puis bon, je veux bien perdre quelques millisecondes à la compil JIT pour avoir un code natif de meilleur qualité et gagner des secondes a l'execution.

Sauf que les développeurs font bien plus de compilations que d'exécutions donc ils risquent de ne voir que le côté péjoratif de la chose.

[adiGuba]

Nouvelle tentative d'explication. Je crois qu'il y a quelques erreurs dans certains des postes ci-dessus.

Très bon résumé bien détaillé

Cela dit, perso, je ne vois pas en quoi on peut espérer des vrais gains de perf à réécrire le compilo JIT en java.

L'intérêt c'est surtout que la JVM pourrait bénéficier des mêmes optimisations que les programmes qu'elle fait tourner.

En effet la compilation JIT peut être très agressive et optimiser le code spécifiquement pour l'architecture sur laquelle elle tourne, chose qu'il peut être difficile à faire en natif sans fournir de multiples exécutables...

Par contre, il semblerait que Graal soit plus instrumentalisable (Des outils style débogueur pourrait se connecter dessus pour avoir plus d'information que ce qui est dispo à l'heure actuelle).
Mais ces fonctionnalités additionnelles auraient certainement pu être ajoutées au projet original.

Il est clairement indiqué que le but recherché c'est de facilité les expérimentations et la recherche. Une JVM en Java et modulable doit grandement faciliter cela

Il reste aussi toute l'initialisation. Car il faut bien partir d'un fichier exécutable nativement (C'est pas pour faire jolie que java.exe, c'est un .exe, pas un .jar...). Et cette initialisation doit être suffisante pour démarrer une VM en java... Cela implique que cette initialisation soit elle même capable de compiler du byte code et en exécuter le résultat, au moins pour démarrer le compilo JIT lui même en byte code.

Il y a quelques années j'avais vu un projet de JVM en Java dont j'ai oublié le nom. Il lui fallait obligatoirement une autre JVM, mais uniquement pour sa toute première exécution. Elle compilait alors en natif son propre code de lancement, ce qui permettait par la suite de l'utiliser indépendamment de toute autres JVMs...

On peut imaginer un mécanisme similaire avec un JVM basique en natif qui serait utilisé uniquement pour lancer Maxine qui s'auto-compilerait en poussant toutes les optimisations à fond...

Bref, un portage du compilo JIT en java, ça va pas changer la face du monde à mon avis.

L'intérêt premier c'est vraiment la recherche et l'expérimentation.
Si ca peut permettre de modifier ou de remplacer facilement des modules de la JVM, ca doit également permettre de la faire évoluer plus vite.

Et là ca pourrait changer pas mal de chose



Cela peut également simplifier le portage de la JVM. Si la vrai JVM super-optimisé est entièrement écrite en Java, et il n'y a plus qu'à utiliser une JVM "lanceur" même simpliste pour la porté sur d'autres systèmes...



Quand au débat sur la performance... là on est vraiment dans le troll



a++


PS : @Robin56 : la compilation JIT concerne l'exécution du programme et n'a rien à voir avec la compilation de javac

[hwoarang]

Nouvelle tentative d'explication. Je crois qu'il y a quelques erreurs dans certains des postes ci-dessus.

Tentative réussie. Je comprends mieux ce qu'est Graal.

L'intérêt c'est surtout que la JVM pourrait bénéficier des mêmes optimisations que les programmes qu'elle fait tourner.

Il y a quelques années j'avais vu un projet de JVM en Java dont j'ai oublié le nom. Il lui fallait obligatoirement une autre JVM, mais uniquement pour sa toute première exécution. Elle compilait alors en natif son propre code de lancement, ce qui permettait par la suite de l'utiliser indépendamment de toute autres JVMs...

On peut imaginer un mécanisme similaire avec un JVM basique en natif qui serait utilisé uniquement pour lancer Maxine qui s'auto-compilerait en poussant toutes les optimisations à fond...

Un peu comme la distrib Linux from scratch Mais bon, si l'objectif est de beneficier de ses propres optimisations, il faut bien qu'elle soit recompilée à chaque fois. Et compiler le compilateur à chaque fois qu'on compile en embarquant 2 compilateurs JIT, ca devient tordu

Bref, comme pas mal de monde apparemment, j'ai du mal à voir le réel avantage par rapport à une amélioration du compilateur JIT (à part pour les developpeurs du compilateur lui meme)...

[pseudocode]

Mais bon, si l'objectif est de beneficier de ses propres optimisations, il faut bien qu'elle soit recompilée à chaque fois. Et compiler le compilateur à chaque fois qu'on compile en embarquant 2 compilateurs JIT, ca devient tordu

On n'a pas besoin de le recompiler à chaque fois, mais juste à l'installation de la VM sur son PC.

C'est comme cela qu'est fabriqué le compilo GCC. Ce compilateur C est écrit... en C.

1. On récupère les sources de GCC et on les compile avec un compilo "simpliste" fourni par le système --> on obtient un GCC-Pass1
2. On recompile les memes sources de GCC avec ce compilo GCC-Pass1 --> on obtient le compilo GCC-Pass2
3. le compilo GCC-Pass2 devient le compilo C par défaut du système.

C'est pas grave si le compilo "simpliste" ne genère pas du code très optimisé. Tout ce qu'il faut c'est que GCC-Pass1 doit fonctionnel, car lui il est capable de générer du code très optimisé.

[adiGuba]

@pseudocode : Excellent exemple que GCC !

D'ailleurs les premiers compilateurs C étaient écrit en assembleur.



En développant une JVM en Java on peut bénéficier de tout les avantages du langage, ce qui devrait faciliter son évolution future, voir même sa portabilité (pour porter le JRE il suffira d'implémenter une JVM basique qui ne sera utilisé qu'une seule fois)



a++

[hwoarang]

On n'a pas besoin de le recompiler à chaque fois, mais juste à l'installation de la VM sur son PC.

C'est comme cela qu'est fabriqué le compilo GCC. Ce compilateur C est écrit... en C.

1. On récupère les sources de GCC et on les compile avec un compilo "simpliste" fourni par le système --> on obtient un GCC-Pass1
2. On recompile les memes sources de GCC avec ce compilo GCC-Pass1 --> on obtient le compilo GCC-Pass2
3. le compilo GCC-Pass2 devient le compilo C par défaut du système.

Oui, c'est comme ca que fonctionne la distrib linux from scratch.
Mais pour revenir à Graal, s'il fonctionne comme ca, je ne vois pas le gain par rapport à un binaire classique à part pour les developpeurs du compilateur en question qui n'auraient plus qu'une version à gérer. Mais du point de vu utilisateur, ca revient au meme (sauf qu'il faut compiler le compilateur en plus)...

[zulad]

Voici un article assez intéressant sur la R&D d'oracle pour java

Java cherche le Graal