Les deux font à peu près la même chose. Identifier que la méthode est chaude et la compiler au lieu de l'interpréter. Avec OSR, vous passez à la version compilée dès qu'elle est compilée, contrairement à JIT, où le code compilé est appelé lorsque la méthode est appelée pour la deuxième fois.
À part cela, y a-t-il d'autres différences ?
En général, Juste à temps La compilation consiste à compiler du code natif au moment de l'exécution et à l'exécuter au lieu (ou en plus) de l'interpréter. Certaines VM, comme Google V8, n'ont même pas d'interpréteur ; elles compilent en JIT chaque fonction exécutée (avec divers degrés d'optimisation).
L'OSR (On Stack Replacement) est une technique permettant de passer d'une implémentation à une autre de la même fonction. Par exemple, vous pouvez utiliser OSR pour passer d'un code interprété ou non optimisé à un code JIT dès la fin de sa compilation.
L'OSR est utile dans les situations où vous identifiez une fonction comme "chaude" pendant son exécution. Ce n'est pas nécessairement parce que la fonction est appelée fréquemment ; elle peut n'être appelée qu'une seule fois, mais elle passe beaucoup de temps dans une grande boucle qui pourrait bénéficier d'une optimisation. Lorsque l'OSR se produit, la VM est mise en pause et le cadre de la pile pour la fonction cible est remplacé par un cadre équivalent qui peut avoir des variables à des emplacements différents.
La RSO peut également se produire dans l'autre sens : du code optimisé au code non optimisé ou au code interprété. Le code optimisé peut faire des suppositions sur le comportement d'exécution du programme en fonction du comportement passé. Par exemple, vous pouvez convertir un appel de méthode virtuelle ou dynamique en un appel statique si vous n'avez jamais vu qu'un seul type d'objet récepteur. S'il s'avère par la suite que ces hypothèses étaient erronées, OSR peut être utilisé pour revenir à une implémentation plus conservatrice : le cadre de pile optimisé est converti en un cadre de pile non optimisé. Si la VM supporte l'inlining, vous pouvez même finir par convertir un cadre de pile optimisé en un cadre de pile non optimisé. plusieurs des trames de piles non optimisées.
Oui, c'est à peu près ça. Compilation juste à temps peut améliorer les performances en compilant les "points chauds" (points du bytecode qui sont connus / supposés s'exécuter très souvent) du bytecode en instructions natives. Remplacement sur la pile complète les capacités JIT en remplaçant le bytecode interprété "chaud" de longue durée par sa version compilée lorsqu'elle est disponible. Le programme mentionné Article sur le remplacement des piles montre un bel exemple où la compilation JIT ne serait pas très utile sans OSR.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
