Quelles sont les différences de JIT entre Java and.Net

Ce sont des bêtes très différentes. Comme les gens l'ont souligné, le CLR se compile en code machine avant d'exécuter un morceau de MSIL. Cela lui permet, en plus de l'élimination typique du code mort et de l'inlining des optimisations privates, de tirer parti de l'architecture CPU particulière de la machine cible (bien que je ne sois pas sûr qu'elle le fasse). Cela entraîne également un succès pour chaque classe (bien que le compilateur soit assez rapide et que de nombreuses bibliothèques de plate-forme ne soient qu'une couche mince sur Win32 API).

La machine virtuelle HotSpot adopte une approche différente. Il stipule que la plupart du code est exécuté rarement, donc il ne vaut pas la peine de passer du temps à le compiler. Tout le bytecode démarre en mode interprété. La machine virtuelle conserve des statistiques sur les sites d'appel et essaie d'identifier les méthodes qui sont appelées plus d'un nombre prédéfini de fois. Ensuite, il compile uniquement ces méthodes avec un compilateur JIT rapide (C1) et échange la méthode pendant son exécution (c'est la sauce spéciale de HS). Après le C1-compilé la méthode a été invoquée plusieurs fois, la même méthode est compilée avec un compilateur lent mais sophistiqué et le code est à nouveau échangé à la volée.

Puisque HotSpot peut échanger des méthodes pendant leur exécution, les compilateurs de machines virtuelles peuvent effectuer des optimisations spéculatives qui ne sont pas sûres dans le code compilé statiquement. Un exemple canonique est la répartition / inlining statique d'appels monomorphes (méthode polymorphe avec une seule implémentation). Ceci est fait si la machine virtuelle voit que cette méthode toujours résout à la même cible. Ce qui était autrefois une invocation complexe est réduit à quelques instructions CPU guard, qui sont prédites et pipelined par les processeurs modernes. Lorsque la condition de garde cesse d'être vraie, la machine virtuelle peut prendre un chemin de code différent ou même revenir en mode d'interprétation. Sur la base des statistiques et de la charge de travail du programme, le code machine généré peut être différent à différents moments. Beaucoup de ces optimisations reposent sur les informations recueillies lors de l'exécution du programme et ne sont pas possibles si vous compilez une fois que vous chargez la classe.

C'est pourquoi vous devez réchauffer la JVM et émuler une charge de travail réaliste lorsque vous comparez des algorithmes (des données biaisées peuvent conduire à une évaluation irréaliste des optimisations). D'autres optimisations sont l'élision de verrouillage, le verrouillage de rotation adaptatif, l'analyse d'échappement et l'allocation de pile, etc.

Cela dit, HotSpot n'est qu'une des machines virtuelles. JRockit, Azul, le J9 d'IBM et le RVM réinitialisable, ont tous des profils de performances différents.