Diferencias entre la compilación Just in Time y On Stack Replacement

Question

Ambos hacen prácticamente lo mismo. Identifique que el método está activo y compílelo en lugar de interpretarlo. Con OSR, simplemente pasa a la versión compilada inmediatamente después de que se compila, a diferencia de JIT, donde se llama al código compilado cuando se llama al método por segunda vez.

Aparte de esto, ¿hay alguna otra diferencia?

Answer 1

En general, Just-in-time compilación se refiere a la compilación de código nativo en tiempo de ejecución y su ejecución en lugar de (o además de) la interpretación. Algunas máquinas virtuales, como Google V8, ni siquiera tienen un intérprete; JIT compila todas las funciones que se ejecutan (con diversos grados de optimización).

On Stack Replacement (OSR) es una técnica para cambiar entre diferentes implementaciones de la misma función. Por ejemplo, puede usar OSR para cambiar de código interpretado o no optimizado a código JIT tan pronto como termine de compilar.

OSR es útil en situaciones en las que identifica una función como "activa" mientras se está ejecutando. Esto puede no ser necesariamente porque la función se llama con frecuencia; podría llamarse solo una vez, pero pasaría mucho tiempo en un gran ciclo que podría beneficiarse de la optimización. Cuando se produce OSR, la máquina virtual se pausa y el marco de pila para la función de destino se reemplaza por un marco equivalente que puede tener variables en diferentes ubicaciones.

OSR también puede ocurrir en la otra dirección: desde código optimizado a código no optimizado o código interpretado. El código optimizado puede hacer algunas suposiciones sobre el comportamiento de tiempo de ejecución del programa en función del comportamiento anterior. Por ejemplo, puede convertir una llamada a método virtual o dinámico en una llamada estática si solo ha visto un tipo de objeto receptor. Si luego resulta que estas suposiciones eran incorrectas, OSR puede usarse para volver a una implementación más conservadora: el marco de pila optimizado se convierte en un marco de pila no optimizado. Si la máquina virtual admite la alineación, es posible que incluso termine convirtiendo una estructura de pila optimizada en varios marcos de pila no optimizados.

Answer 2

Sí, eso es más o menos. Just-in-time compilation puede mejorar el rendimiento al compilar "puntos calientes" (puntos de bytecode que se sabe/se supone que se ejecutan muy a menudo) de bytecode a instrucciones nativas. On-Stack Replacement complementa las capacidades de JIT al reemplazar el bytecode interpretado de ejecución larga por su versión compilada cuando esté disponible. El mencionado On-Stack Replacement article muestra un buen ejemplo donde la compilación JIT no sería muy útil sin OSR.

Answer 3

La gente ya mencionó lo que es JIT.

en columna de reposición (OSR)

Cuando la JVM ejecuta un método de Java, comprueba la suma del número de veces que el método ha sido llamado, y el número de veces que los bucles en el método se ha bifurcado y decide si el método es elegible o no para la compilación. Si es así, el método está en cola para la compilación. Este tipo de compilación no tiene un nombre oficial, pero a menudo se llama estándar compilación.

Pero, ¿y si el método tiene un bucle realmente largo, o uno que nunca sale, y proporciona a todos la lógica del programa? En ese caso, la JVM necesita compilar el bucle sin esperar para una invocación al método.Por lo tanto, cada vez que el ciclo completa una ejecución, el contador de bifurcación se incrementa e inspecciona. Si el contador de bifurcación ha excedido su umbral individual , entonces el bucle (y no todo el método) pasa a ser elegible para la compilación . Este tipo de recopilación es llamada en columna de reposición (OSR), porque incluso si el bucle se compila, eso no es suficiente: la JVM tiene que tener la capacidad de iniciar la ejecución de la versión compilada de la bucle mientras el bucle todavía se está ejecutando. Cuando el código para el ciclo ha terminado de compilarse, la JVM reemplaza el código (en la pila), y la siguiente iteración de el ciclo ejecutará la versión compilada mucho más rápida del código.