À mon avis grâce à gcc, il est nettement plus simple de faire un compilateur de code Java qu'une JVM qui speed sa race ... euh qu'une JVM très performante (ouf). Si "transcription" du bytecode en assembleur peut sembler identique entre un compilateur "normal" et un compilateur JIT (cJIT) il y a malgré tout quelques différences pas négligeables :
un cJIT doit être rapide car la compilation de bytecode entre dans le temps d'exécution ; au démarrage mais aussi durant l'exécution si une classe est chargée à la volée il est hors de question d'attendre 2 minutes que le compilateur ait terminé de la traiter ;
un cJIT doit être capable d'optimiser le code en prennant en compte des paramètres qui ne sont disponibles qu'à l'exécution ;
la JVM doit pouvoir faire des stats sur l'utilisation des portions de code et demander à au compilateur de recompiler une partie de code avec une optimisation plus poussée.
C'est donc quelque chose de totalement différent de créer un compilateur pour un nouveau langage en s'appuyant sur Gcc.
[^] # Re: hum
Posté par gabuzo . En réponse à la dépêche Eclipse compilé en natif.. Évalué à 2.
- un cJIT doit être rapide car la compilation de bytecode entre dans le temps d'exécution ; au démarrage mais aussi durant l'exécution si une classe est chargée à la volée il est hors de question d'attendre 2 minutes que le compilateur ait terminé de la traiter ;
- un cJIT doit être capable d'optimiser le code en prennant en compte des paramètres qui ne sont disponibles qu'à l'exécution ;
- la JVM doit pouvoir faire des stats sur l'utilisation des portions de code et demander à au compilateur de recompiler une partie de code avec une optimisation plus poussée.
C'est donc quelque chose de totalement différent de créer un compilateur pour un nouveau langage en s'appuyant sur Gcc.