Pourquoi la JVM ne met-elle pas en cache le code compilé par JIT ?

Question

L'implémentation canonique de la JVM de Sun applique une optimisation assez sophistiquée au bytecode afin d'obtenir des vitesses d'exécution quasi-natives après que le code ait été exécuté plusieurs fois.

La question est de savoir pourquoi ce code compilé n'est pas mis en cache sur le disque pour être utilisé lors des utilisations ultérieures de la même fonction/classe.

Actuellement, chaque fois qu'un programme est exécuté, le compilateur JIT s'active à nouveau, au lieu d'utiliser une version précompilée du code. L'ajout de cette fonctionnalité ne permettrait-il pas d'augmenter considérablement le temps d'exécution initial du programme, lorsque le bytecode est essentiellement interprété ?

Answer 1

JVM d'Oracle est en effet documenté pour le faire -- citant Oracle,

le compilateur peut tirer parti du modèle de résolution de classe d'Oracle JVM pour pour faire persister les méthodes Java compilées compilées à travers les appels à la base de données, sessions ou instances. Une telle persistance persistance permet d'éviter les surcharges de recompilations inutiles entre les sessions ou instances, lorsque l'on sait que lorsque l'on sait que sémantiquement le code Java n'a pas changé.

Je ne sais pas pourquoi toutes les implémentations sophistiquées de VM ne proposent pas des options similaires.

Answer 2

Sans avoir recours à un copier-coller du lien que @MYYN a posté, je soupçonne que c'est parce que les optimisations que la JVM effectue ne sont pas statiques, mais plutôt dynamiques, basées sur les modèles de données ainsi que sur les modèles de code. Il est probable que ces modèles de données changent pendant la durée de vie de l'application, rendant les optimisations en cache moins qu'optimales.

Il faudrait donc un mécanisme permettant de déterminer si les optimisations sauvegardées sont toujours optimales, auquel cas il serait tout aussi bien de les réoptimiser à la volée.

Answer 3

Une mise à jour des réponses existantes - Java 8 a un JEP dédié à la résolution de ce problème :

\=> JEP 145 : Cache du code compilé . Nouveau lien .

À un niveau très élevé, il a déclaré L'objectif est :

Sauvegarder et réutiliser le code natif compilé des exécutions précédentes afin de améliorer le temps de démarrage des grandes applications Java.

J'espère que cela vous aidera.

Answer 4

Excelsior JET possède un compilateur JIT de cache depuis la version 2.0, sortie en 2001. De plus, son compilateur AOT peut recompiler le cache en une seule DLL/objet partagé en utilisant toutes les optimisations.

Answer 5

Je ne connais pas les raisons réelles, n'étant pas impliqué de quelque manière que ce soit dans l'implémentation de la JVM, mais je peux penser à quelques raisons plausibles :

• L'idée de Java est d'être un langage qui s'écrit une fois et s'exécute partout, et mettre du matériel précompilé dans le fichier de classe est en quelque sorte une violation de cela (seulement "en quelque sorte" parce que bien sûr le code d'octet réel serait toujours là).
• Cela augmenterait la taille des fichiers de classe parce que vous auriez le même code plusieurs fois, surtout si vous exécutez le même programme sous plusieurs JVM différentes (ce qui n'est pas vraiment rare, si vous considérez les différentes versions comme des JVM différentes, ce que vous devez vraiment faire).
• Les fichiers de classe eux-mêmes peuvent ne pas être accessibles en écriture (bien qu'il soit assez facile de le vérifier).
• Les optimisations de la JVM sont partiellement basées sur des informations d'exécution et sur d'autres exécutions, elles pourraient ne pas être aussi applicables (bien qu'elles devraient toujours fournir un certain avantage).

Mais je suis vraiment en train de deviner, et comme vous pouvez le voir, je ne pense pas vraiment qu'aucune de mes raisons soit un obstacle réel. Je pense que Sun ne considère tout simplement pas ce support comme une priorité, et peut-être que ma première raison est proche de la vérité, car faire cela de manière habituelle pourrait aussi amener les gens à penser que les fichiers de classe Java ont vraiment besoin d'une version séparée pour chaque VM au lieu d'être multiplateforme.

Ma préférence irait en fait à un traducteur bytecode-natif distinct que vous pourriez utiliser pour faire quelque chose comme ça explicitement à l'avance, en créant des fichiers de classe qui sont explicitement construits pour une VM spécifique, avec éventuellement le bytecode d'origine en eux afin que vous puissiez fonctionner avec différentes VM aussi. Mais cela vient probablement de mon expérience : J'ai surtout travaillé sur Java ME, où le compilateur Java n'est pas plus intelligent pour la compilation.