Java acelera el arranque con compilación AOT en la JVM HotSpot
JEP 544: Ahead-of-Time Code Compilation
El JEP 544 propone almacenar código nativo optimizado en la caché AOT durante una ejecución de entrenamiento, para que HotSpot lo cargue al instante en producción. Esto reduce el tiempo de arranque entre un 65% y un 80% y mejora el calentamiento, manteniendo la capacidad de desoptimizar y reoptimizar si cambia la carga de trabajo. No requiere modificar el código de las aplicaciones ni la configuración de HotSpot.
La tesis de Project Leyden es que la clave para mejorar el tiempo de arranque y calentamiento es hacer parte de este trabajo antes, de forma anticipada, en lugar de solo a tiempo.
- cogman10
Leyden ha estado dependiendo bastante de las ejecuciones de entrenamiento, lo entiendo, pero hombre, eso es una carga bastante difícil de configurar.
Las herramientas para hacer este tipo de ejecuciones de entrenamiento realmente no existen, terminas necesitando hacer algo más a medida como parte de tu pipeline de build si quieres tenerlo ahí. Eso puede ser especialmente complicado con aplicaciones más complejas como las que mantengo.
Me gusta lo que esto puede ofrecer, pero no me gusta el esfuerzo necesario para ponerlo en marcha.
- treyd
¿Cuáles son las diferencias arquitectónicas entre esto y el runtime ahead-of-time de Android?
- cyberax
Excelsior JET hizo eso hace 25 años: https://en.wikipedia.org/wiki/Excelsior_JET
Es una lástima que Sun/Oracle nunca se asociara con ellos para traer aplicaciones nativas. Esto podría haber salvado a Java en el escritorio.
- java-man
Espero que en algún momento tengamos un modo solo AOT (o compilar a nativo) y quizás incluso compilación cruzada.
- ledo9915
Un dato de un pequeño proyecto secundario: ejecuto código de usuario en un sandbox de Piston para un sitio de desafíos de programación. Un programa Java trivial cuesta 2.5-3 s de reloj de pared en una máquina de 4 vCPU, casi todo es javac más el arranque de la JVM. Go tarda unos 1.7 s para build más ejecución, y Swift ejecutándose a través del intérprete está en 0.4 s. Java es la razón por la que tuve que poner un límite de tasa global en los lenguajes compilados. Si AOT reduce el lado de la JVM a unos pocos cientos de ms, eso cambia lo que una máquina pequeña puede servir.