En quoi un compilateur JIT est-il différent d'un compilateur ordinaire?

Il y a eu beaucoup de battage médiatique sur les compilateurs JIT pour des langages comme Java, Ruby et Python. En quoi les compilateurs JIT sont-ils différents des compilateurs C / C ++, et pourquoi les compilateurs sont-ils écrits pour Java, Ruby ou Python appelés compilateurs JIT, alors que les compilateurs C / C ++ sont simplement appelés compilateurs?

Les compilateurs JIT compilent le code à la volée, juste avant leur exécution ou même lorsqu'ils sont déjà en cours d'exécution. De cette façon, la machine virtuelle sur laquelle le code s'exécute peut rechercher des modèles dans l'exécution du code pour permettre des optimisations qui ne seraient possibles qu'avec des informations d'exécution. De plus, si la machine virtuelle décide que la version compilée n'est pas assez bonne pour quelque raison que ce soit (par exemple, trop de ratés de cache ou de code lançant fréquemment une exception particulière), elle peut décider de la recompiler d'une manière différente, conduisant à une solution beaucoup plus intelligente. compilation.

De l'autre côté, les compilateurs C et C ++ ne sont traditionnellement pas JIT. Ils compilent en une seule fois une seule fois sur la machine du développeur, puis un exécutable est produit.

JIT est l'abréviation de compilateur juste à temps, et son nom est misson: pendant l'exécution, il détermine les optimisations de code intéressantes et les applique. Il ne remplace pas les compilateurs habituels mais fait partie des interprètes. Notez que les langages comme Java qui utilisent du code intermédiaire ont les deux : un compilateur normal pour la traduction du code source vers le code intermédiaire, et un JIT inclus dans l'interpréteur pour augmenter les performances.

Les optimisations de code peuvent certainement être effectuées par des compilateurs "classiques", mais notez la principale différence: les compilateurs JIT ont accès aux données lors de l'exécution. C'est un énorme avantage; l'exploiter correctement peut être difficile, évidemment.

Considérez, par exemple, un code comme celui-ci:

m(a : String, b : String, k : Int) {
  val c : Int;
  switch (k) {
    case 0 : { c = 7; break; }
    ...
    case 17 : { c = complicatedMethod(k, a+b); break; }
  }

  return a.length + b.length - c + 2*k;
}

Un compilateur normal ne peut pas en faire trop. Un compilateur JIT, cependant, peut détecter que l' mon n'appelle jamais avec k==0pour une raison quelconque (des choses comme cela peuvent se produire lorsque le code change avec le temps); il peut ensuite créer une version plus petite du code (et le compiler en code natif, bien que je considère cela comme un point mineur, conceptuellement):

m(a : String, b : String) {
  return a.length + b.length - 7;
}

À ce stade, il va probablement même incorporer l'appel de méthode car il est trivial maintenant.

Apparemment, le Soleil a rejeté la plupart des optimisations javacutilisées dans Java 6; On m'a dit que ces optimisations ont rendu difficile pour JIT de faire beaucoup, et le code compilé naïvement a finalement fonctionné plus rapidement. Allez comprendre.