OpenJDK propone en el JEP 544 mezclar compilación AOT y JIT en HotSpot

El JEP 544 propone que HotSpot combine compilación ahead-of-time (AOT) y just-in-time (JIT) en la misma ejecución. La JVM compilaría el código de la aplicación a nativo durante una ejecución de entrenamiento, guardaría ese código en la caché AOT y lo tendría listo al arrancar en producción. Si la carga cambia, HotSpot vuelve a compilar en caliente las partes que hagan falta para mantener el rendimiento. El objetivo es acortar el arranque y el warmup sin pedir cambios en el código de aplicaciones, librerías ni frameworks.

HotSpot pasa hoy por tres fases: arranque, calentamiento y rendimiento máximo. Al principio ejecuta bytecode en el intérprete y perfila métodos y bucles; después usa C1 para compilar lo más caliente y, cuando el perfil gana calidad, entra C2 con código nativo muy optimizado. Ese proceso consume CPU y memoria, y el código instrumentado no corre igual que el no instrumentado. La propuesta quiere que parte de ese trabajo ya esté hecho antes de que la aplicación reciba tráfico.

El JEP no inventa un flujo nuevo: extiende el mecanismo actual de creación de la caché AOT. Para usarlo, el despliegue pide la caché AOT; no hace falta tocar la configuración de HotSpot más allá de eso. La transición entre código AOT y código JIT debe ser invisible para la aplicación, y se mantienen los recolectores Serial, Parallel, G1 y ZGC. La propuesta cubre AArch64 y x64.

Hay límites claros. No habrá un modo solo AOT: la aplicación usará código AOT y JIT en la misma ejecución y saltará de uno a otro según convenga. Tampoco hay compilación cruzada. El código generado en la ejecución de entrenamiento debe ejecutarse en la misma arquitectura de CPU y con el mismo conjunto de características en producción; si cambia el procesador o faltan instrucciones, no sirve. El JEP tampoco promete soportar todas las arquitecturas que HotSpot admite ahora, aunque espera que el portado normal acabe cubriendo las principales.

El trabajo encaja en el proyecto Leyden, cuyo repositorio incluye benchmarks y material de seguimiento. También responde a una discusión vieja: por qué no compilar todo estáticamente. Un compilador estático entrega código nativo antes de ejecutar y elimina el warmup, pero se queda atado a un conjunto de métodos calientes y a un entorno concreto. La compilación dinámica reacciona a cambios en la carga, deoptimiza y reoptimiza, y genera código para la CPU, el sistema operativo y la versión de JDK que se estén usando. El JEP 544 intenta quedarse con lo bueno de ambos: arranque rápido con AOT y capacidad de reacción con JIT.

Para quien administra JVM en producción, la promesa es concreta: menos tiempo hasta el pico y menos coste de calentamiento en cada arranque o despliegue. La condición es igualmente concreta: la ejecución de entrenamiento debe parecerse al entorno real, misma arquitectura y mismas características de CPU. Queda por ver cómo se comporta con cargas que cambian mucho y cuánto ocupa la caché AOT en disco y memoria. Si el flujo termina en una versión estable de OpenJDK, actualizar la JVM podría dejar de ser solo un cambio de versión y pasar a requerir una etapa de entrenamiento en el pipeline.