Pourquoi Java's Jit Compiler ne traduita-t-il pas tout en code natif?

Si vous exécutez un point jvm comme hotspot, il compile de manière opportuniste, ce qui ne se concentre que sur le code qui exécute fréquemment. Il détermine le code à optimiser à la volée en comptant la fréquence de chaque bloc de code (ou méthode - je ne suis pas sûr que). Par conséquent, au moment du démarrage, tout est interprété.

L'intention derrière cela est permettant d'optimiser beaucoup plus agressifs et coûteux en nécessitant une petite fraction du code à optimiser.

Tout est une question de compromis

• Le temps nécessaire pour compiler + le code exécuté peut être plus long que le temps d'interpréter une fois
• Vous pouvez souvent optimiser les choses beaucoup plus efficacement si vous avez des statistiques sur la ramification, etc.
• Certaines choses ne peuvent pas être compilées (tout ce qui fait RTTI, probablement)
• Certaines choses que vous ne voulez pas compiler (numéros de ligne pour les traces de pile, etc.)
• Je suis sûr qu'il y a d'autres.

Deux raisons principales:

• L'interprétation n'est pas plus lente si le code n'est exécuté que quelques fois. Le coût de la compilation seul peut être beaucoup plus cher que d'interpréter le code s'il ne s'agit que de plusieurs fois.
• En interprétant, il est possible de rassembler des statistiques au moment de l'exécution utiles pour optimiser le code plus tard. Par exemple, vous pouvez compter le nombre de fois qu'une branche particulière est prise et optimise le code pour être plus rapide pour le cas plus fréquent. Ce type de truc peut mieux rendre la compilation JIT que la compilation à l'avance (qui n'a pas la possibilité d'exploiter les statistiques d'exécution)

  Par conséquent, le Java Jit prend une stratégie sensible: ne compilez pas tant que vous observerez que le même code est exécuté à plusieurs reprises, à quel point vous avez des preuves que la compilation est probablement la peine et que vous êtes en mesure de faire des informations supplémentaires. optimisations.