IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

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 !

Graal : le compilateur dynamique Java pourrait être utilisé dans les JVM
Pour de meilleures performances

Le , par Hinault Romaric

10PARTAGES

6  0 
La communauté du projet Graal et les développeurs d’Oracle souhaiteraient que le compilateur soit utilisé dans des machines virtuelles Java (JVM).

Le projet Graal est une mise en œuvre d’un compilateur dynamique en Java, qui permet de produire du code de bonne qualité sans compromettre le temps de compilation et l’utilisation de la mémoire dans la machine virtuelle Java.

Pour améliorer les performances des JVM, des représentants d’Oracle et les participants au groupe de discussion OpenJDK ont commencé à explorer dans des échanges par messagerie électronique, la mise en œuvre d’un compilateur dynamique qui pourrait être utilisé dans une machine virtuelle Java native comme HotSpot ou méta-circulaire comme Maxine.

La machine virtuelle Maxine est une plateforme de prochaine génération, écrite en Java, disposant d’une architecture modulaire et compatible avec les environnements de développement et le SDK Java modernes, selon Oracle. Le compilateur Graal basé sur le code de Maxine, servirait de point de départ au projet de compilateur dynamique.

« Ce qui est clair ici, c’est que Graal permet d’obtenir de meilleures performances de compilation à partir de Java » a déclaré l’analyste Al Hilwa d’IDC. « Il y a un mouvement de retour à l’origine [vers le code natif], à bien des égards stimulé par les outils d’Apple pour le développement iOS, qui tourne autour d’un modèle natif compilé pour Objective-C. Pendant longtemps, la balance penchait en faveur des langages des machines virtuelles comme Java. Mais le succès d’iOS a changé la tendance. Dans ce contexte, Java doit améliorer ses performances pour être comparable avec ce qui est possible avec les compilateurs natifs et aussi évoluer en terme d’intégration de code natif ».

L’idée d’utiliser Graal dans les machines virtuelles Java est très appréciée par plusieurs utilisateurs du langage. « Pensez à coder en Java, le compiler en utilisant un compilateur écrit en Java, et en l’exécutant dans la JVM, qui est également écrite en Java. Java est présent sur toute la chaine et ouvre le chemin à une intégration transparente entre l’application et la VM » a déclaré Hari Gottipati, architecte principal chez Apollo Group, de l’université de Phœnix. « Je suis sûr que toute la communauté Java va être excitée à ce sujet ».

Graal à fait l’objet d’une présentation en juillet dernier par Oracle lors de l’événement JVM Language Summit. Les travaux sur Graal devraient être complétés par la publication du JDK 8 en 2013.

Source : Wiki de la JVM Maxine

Et vous ?

Que pensez-vous de l'utilisation d'un compilateur dynamique dans les JVM ?

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

Avatar de rt15
Membre éclairé https://www.developpez.com
Le 16/02/2012 à 18:51
Nouvelle tentative d'explication. Je crois qu'il y a quelques erreurs dans certains des postes ci-dessus.

1/ Rappel de l'utilisation classique de java.

Il y a deux phases pour passer du sources à l'exécutions :

Ce que fait le développeur sur son poste ou autre serveur de compile :
Code java (.java) -> [ javac.exe (JDK) ] -> Byte code java (.class).
Ce qui se passe sur la machine utilisateur :
Byte code java (.class) -> [ java.exe (JVM/JRE) ] -> Code machine.

Java.exe est une une jvm. Elle inclut un compilo JIT (Qui compile au fil de l'eau) depuis le byte code vers le code machine processeur. Puis le code machine processeur est exécuté.

2/ Maxine

Maxine est simplement une JVM, mais écrite en java.
Elle peut remplacer la JVM hotspot... Mais elle a besoin d'une autre jvm pour tourner !



3/ C1X

C'est le nom du compilo JIT de Maxine. Il s'agit globalement du compilo JIT de hotspot (C1), mais réécrit en java.

4/ Graal

Graal s'appelait auparavant le projet C1X4HotSpot.

Comme ce nom l'indiquait mieux, le but de Graal est de transformer C1X pour le porter sur hotspot. Pour ça il on fait tout un tas d'interfaces pour que C1X puisse s'intégrer dans un peu tout et n'importe quoi.
Donc historiquement:
C1 (Dans Hotspot) -> C1X (Dans Maxine) -> Graal (Dans Hotspot, et d'autres).

A terme, il est prévu que Graal remplace aussi C1X dans Maxine. Mais la priorité des devs est actuellement le port dans la hotspot.

5/ Troll

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.
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.

« Pensez à coder en Java, le compiler en utilisant un compilateur écrit en Java, et en l’exécutant dans la JVM, qui est également écrite en Java. Java est présent sur toute la chaine et ouvre le chemin à une intégration transparente entre l’application et la VM »
Alors lui il est sous acide et je ne sais pas de quoi il parle.
Si c'est de Maxine, alors il oublie que sous sa belle jvm java, il y a une autre jvm.
Si c'est de graal dans hotspot, alors il oublie que le compilo JIT n'est pas tout à fait le seul composant d'une jvm.

Il reste tout ce qui se trouve entre les classes standards et l'OS.
Exemple classes d'accès au fichiers -> CreateFile sous windows et open (Ou fopen) sous unix.

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.

Bref, un portage du compilo JIT en java, ça va pas changer la face du monde à mon avis.
5  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 17/02/2012 à 9:02
Citation Envoyé par rt15 Voir le message
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é

Citation Envoyé par rt15 Voir le message
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...

Citation Envoyé par rt15 Voir le message
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

Citation Envoyé par rt15 Voir le message
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...

Citation Envoyé par rt15 Voir le message
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
2  0 
Avatar de spyserver
Membre confirmé https://www.developpez.com
Le 15/02/2012 à 9:56
En gros actuellement on a :

Objective-C -> [compilateur] -> Code natif (assembleur) <- Performant

Java -> [compilateur JIT codé en C ou autre] -> byteCode -> JVM <- Moins performant

Désormais ils veulent faire ça :

Java -> [Graal codé en Java] -> byteCode de meilleure qualité -> JVM

Enfin c'est ce que j'ai compris ...
1  0 
Avatar de Robin56
Modérateur https://www.developpez.com
Le 15/02/2012 à 16:48
On ne comprend rien mais ça s'appelle Graal, ça doit donc surement être bien

Citation Envoyé par HS
- Que voulez-vous ?
- Nous voulons ... un Jardinet ! (Ni Ni Ni ...)
Excusez moi pour ce moment d'égarement..
1  0 
Avatar de Nudger
En attente de confirmation mail https://www.developpez.com
Le 15/02/2012 à 19:57
Ce que j'en comprend: l'objectif est de produire du code natif qui puisse s'appuyer sur la JVM pour la gestion des objets mémoire.

Dans un premier temps, on pourrait imaginer que le compilateur (javac) produise directement du bytecode. Sauf que si tel est le cas, l'objet compilé n'a plus l'avantage d'être portable entre différents matériels ou OS.

Pour conserver la portabilité des livrables, la conversion du bytecode en code natif est faite au runtime => c'est à ça que semble servir GRAAL et il est donc embarqué dans le JRE.

Les applis iOS sont plus performantes car natives c'est un fait mais elles ne sont pas portables, ce dont apple se fiche car elles n'ont pas vocation à tourner ailleurs que sur leurs propres matériel.
1  0 
Avatar de Népomucène
Modérateur https://www.developpez.com
Le 16/02/2012 à 19:30
Citation Envoyé par rt15 Voir le message

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>
1  0 
Avatar de pseudocode
Rédacteur https://www.developpez.com
Le 17/02/2012 à 11:34
Citation Envoyé par hwoarang Voir le message
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é.
1  0 
Avatar de Flaburgan
Modérateur https://www.developpez.com
Le 15/02/2012 à 8:53
Quelque chose que je ne comprends pas : pour s'exécuter, le bytecode java à besoin d'une machine virtuelle. Si la machine est elle même écrite en java, comment faut-elle pour s'exécuter ?
0  0 
Avatar de Niark13
Membre éclairé https://www.developpez.com
Le 15/02/2012 à 9:01
En gros, on peut dire que Graal est à Java ce que Pypy est à Python, c'est ça ?
0  0 
Avatar de JoeChip
Membre éclairé https://www.developpez.com
Le 15/02/2012 à 9:11
Pensez à coder en Java, le compiler en utilisant un compilateur écrit en Java, et en l’exécutant dans la JVM, qui est également écrite en Java
Euh, traduction approximative ?
0  0