Comprendre les différences entre compilation statique et dynamique en Java

Très bon article de vulgarisation pour les gens qui veulent connaître Hotspot

Détails:
Tired compilation -> Tiered
TiredCompilation -> Tiered
Figure 3 : Cycle de vie du -> il manque la fin "bytecode" d'après l'article de base
plus de détail) -> détails
Dead code Elimination -> Dead Code
StringBufffer -> StringBuffer
threadSafe -> ThreadSafe
elision -> Elision
garbage collector GC -> Garbage Collector (GC)
plus que de raison -> ne veut rien dire ... plus qu'il ne faille?
L'analyse de l'échappement -> Pas que je suis contre faire des traductions comme cela mais vous avez écrit "Escape Analysis" au début de la section... faut se décider: est-ce qu'on utilise les mots de la littérature et du monde de la compilation en anglais ou est-ce qu'on les rend français: Note je suis contre les écrire en français dans ce cas: le lecteur ne pourra pas trouver d'information supplémentaire dans ce cas...
static . -> espace inutile

Remarques pointilleuses:
Selon une publication d'Eva Andreasson, le gain est un code jusqu'à dix fois plus performant que celui produit par une compilation C0 -> Très discutable. Si on prend n'importe quel code, on peut avoir une optimisation infinie... dire 10x ici n'est qu'une phrase sans but en fait...

Cette partie est inutile:
Objets stockés dans des champs static .
Objets qui sont des attributs d'un autre objet lui-même sujet à l'échappement.
Objets créés, retournés ou non à la fin de l'exécution d'une méthode.
Objets créés à l'intérieur d'une boucle.

vous ne donnez pas assez de détail pour expliquer qu'en gros le compilateur doit prouver que l'objet est créé mais qu'on peut prouver sa mort et donc qu'on peut virer l'allocation sur le tas...

Troll possible:
Techniquement le code montré est incomplet: on ne sait pas ce qu'il se passe dans les appels de fonctions/constructeurs. Il est possible que le code fasse des choses complexes et donc le compilateur ne pourrait rien faire. Je suis pointilleux je sais mais si on suppose qu'on ne sait rien, on ne peut rien faire.

On peut en discuter longtemps:
"Dans ces conditions, et en s'appuyant sur les statistiques d'exécution, la JVM peut décider de ne pas vérifier quelle implémentation ou surcharge de la méthode il faut invoquer." -> non la JVM devra très souvent vérifier quelle implémentation il faut invoquer. La dévirtualisation ne se fait que dans certains cas et ce ne sera jamais parce que pendant l'interprétation ou l'exécution en C1 on ne voit pas de destinations multiples. Si on ne peut pas prouver que ce n'est pas virtuel, on aura un grand if avant l'appel qui sera d'un côté rapide et l'autre lent... En gros, cette explication est trompeuse.

Autre troll:
"C++... car ce dernier ne peut pas éliminer aussi facilement ce coût de vérification." -> oui car le C++ ne vient pas avec le tiered compilation et la JVM autour...

Dernier détail :
"par la compilation JIT" -> inlining peut être fait statiquement aussi. Il se trouve qu'en Java, ce n'est pas fait à cause de la virtualisation...

Encore une fois, super de voir cela sur developpez.com
Jc