On part sur un mode d'exécution interprété. On exécute le bytecode dans la JVM, à chaque instruction correspond une translation sur la machine cible. Quand une instruction à été exécutée on passe à la suivante.
Si Hotspot détecte que ça en vaut le coup, alors on produit du langage machine qui correspond, à peu près, au bytecode (si ca répond à ta question ce qu'on appel assembleur ce sont des symbole mnémoniques qui seront ensuite traduit en langage machine, une suite de bits). On se passera donc de l'étape de translation pour les prochaines exécutions. On peut faire des optims assez malines grâce au fait que l'on a accès à beaucoup d'informations: stats des exécutions précédentes, proco cible etc. Dans Hotspot il y a deux compilateurs qui sont plus ou moins agressifs.
Je disais à peu près car Hotspot est capable de faire de la désoptimisation. C'est à dire qu'il se permet de générer des optimisations non sûres reposant sur des hypothèses qui peuvent devenir fausses. Si il se rend compte à l'exécution que les hypothèses qu'il avait fait deviennent erronées, alors il remplace la frame optimisée par une autre moins optimisée et c'est reparti. Il se passe la même chose si entre la première moitié et la seconde de programme les prédiction de branches changent du tout au tout.
[^] # Re: Grandiose
Posté par ckyl . En réponse au journal Linuxfr en J2EE. Évalué à 10.
http://en.wikipedia.org/wiki/Java_performance#Just-In-Time_c(...)
Voici un résumé très grossier:
On part sur un mode d'exécution interprété. On exécute le bytecode dans la JVM, à chaque instruction correspond une translation sur la machine cible. Quand une instruction à été exécutée on passe à la suivante.
Si Hotspot détecte que ça en vaut le coup, alors on produit du langage machine qui correspond, à peu près, au bytecode (si ca répond à ta question ce qu'on appel assembleur ce sont des symbole mnémoniques qui seront ensuite traduit en langage machine, une suite de bits). On se passera donc de l'étape de translation pour les prochaines exécutions. On peut faire des optims assez malines grâce au fait que l'on a accès à beaucoup d'informations: stats des exécutions précédentes, proco cible etc. Dans Hotspot il y a deux compilateurs qui sont plus ou moins agressifs.
Je disais à peu près car Hotspot est capable de faire de la désoptimisation. C'est à dire qu'il se permet de générer des optimisations non sûres reposant sur des hypothèses qui peuvent devenir fausses. Si il se rend compte à l'exécution que les hypothèses qu'il avait fait deviennent erronées, alors il remplace la frame optimisée par une autre moins optimisée et c'est reparti. Il se passe la même chose si entre la première moitié et la seconde de programme les prédiction de branches changent du tout au tout.
La JVM est vraiment une merveille d'optimisations (qu'on aime ou pas ce qui se trouve dessus). Les travaux sur le locking , les optimisations du compilateur, ou le garbage collector sont assez impressionnants. Voir: http://java.sun.com/products/hotspot/whitepaper.html
et http://java.sun.com/javase/technologies/hotspot/publications(...)