Le mode interprété pur :
Il s'agit d'une interprétation à 100% par la machine virtuelle. La VM est alors un émulateur de machine Java, dont le code machine serait le bytecode. Ce procédé est performant lorsque beaucoup de classes sont utilisées et que chaque ligne de code est appelée peu souvent.
Ce mode est celui par défaut des JDK 1.0.x et de quelques implémentations de 1.1.x.
La compilation avec JIT :
Le bytecode est entièrement compilé en code machine correspondant à la platteforme matérielle existant sous la VM. La compilation a lieu pendant le chargement de toute nouvelle classe. Cela implique un temps de chargement de classe plus long et plus de mémoire utilisée, mais améliore énormément les performances pour les boucles ayant beaucoup d'itérations.
Ce mode est celui par défaut de la plupart des JDK 1.1.x, du J2SE 1.2.x de SUN et, à ma connaissance, de toutes les implémentations Java2 autres que celles de SUN.
Le mode mixte :
Il s'agit (à ma connaissance) de la dernière inovation dans le domaine et du meilleur compromis pour la vitesse et la consommation mémoire. Dans un premier temps, le bytecode est interprété. Puis, si la VM se rend compte qu'un groupe d'instructions est très souvent exécuté, elle compile cette section à la volée et en tâche de fond. Dès que la compilation est terminée, la version compilée remplace la version interprétée de la section. Dans le même ordre d'idées, si une section compilée n'est plus appelée pendant un certain temps, la version compilée est effacée de la mémoire et on repasse en mode interprété pour cette section.
Ce mode est implémenté par HotSpot de SUN, disponible en plug-in pour le J2SE 1.2.x et en standard sur le J2SE 1.3.x. Je ne connais pas d'autre implémentation de ce mécanisme.
[^] # Re: WORA + Java, favori pour OSX ?
Posté par François B. . En réponse à la dépêche Java sur Mac OS X. Évalué à 1.
Il s'agit d'une interprétation à 100% par la machine virtuelle. La VM est alors un émulateur de machine Java, dont le code machine serait le bytecode. Ce procédé est performant lorsque beaucoup de classes sont utilisées et que chaque ligne de code est appelée peu souvent.
Ce mode est celui par défaut des JDK 1.0.x et de quelques implémentations de 1.1.x.
Le bytecode est entièrement compilé en code machine correspondant à la platteforme matérielle existant sous la VM. La compilation a lieu pendant le chargement de toute nouvelle classe. Cela implique un temps de chargement de classe plus long et plus de mémoire utilisée, mais améliore énormément les performances pour les boucles ayant beaucoup d'itérations.
Ce mode est celui par défaut de la plupart des JDK 1.1.x, du J2SE 1.2.x de SUN et, à ma connaissance, de toutes les implémentations Java2 autres que celles de SUN.
Il s'agit (à ma connaissance) de la dernière inovation dans le domaine et du meilleur compromis pour la vitesse et la consommation mémoire. Dans un premier temps, le bytecode est interprété. Puis, si la VM se rend compte qu'un groupe d'instructions est très souvent exécuté, elle compile cette section à la volée et en tâche de fond. Dès que la compilation est terminée, la version compilée remplace la version interprétée de la section. Dans le même ordre d'idées, si une section compilée n'est plus appelée pendant un certain temps, la version compilée est effacée de la mémoire et on repasse en mode interprété pour cette section.
Ce mode est implémenté par HotSpot de SUN, disponible en plug-in pour le J2SE 1.2.x et en standard sur le J2SE 1.3.x. Je ne connais pas d'autre implémentation de ce mécanisme.