JEP 544 lleva la compilación AOT nativa a la JVM de Java

Qué trae JEP 544 y por qué importa a tu backend

JEP 544 (Candidate) es la pieza que faltaba en Project Leyden: después de que JEP 483 (JDK 24) adelantara la carga y el linkage, y de que JEP 515 (JDK 25) adelantara el perfilado de métodos, ahora la propia compilación nativa optimizada con C2 se ejecuta en una training run y se guarda en el AOT cache, lista para ser cargada en el siguiente arranque en milisegundos. Es la culminación de la estrategia de OpenJDK para hacer que Java arranque rápido, escale bien en contenedores y deje de pagar la warmup penalty en cada despliegue.

El dato clave de la propuesta: en cinco benchmarks con frameworks populares medidos en un Linux/x64 de dos núcleos (escenario típico de microservicio compitiendo por CPU con el JIT), el AOT cache sin código AOT recorta el arranque entre un 50% y un 70%; con código AOT, la mejora sube a un rango de 65% a 80% según el JEP. Y en el benchmark de javac que compila 50 fuentes veinte veces, la primera iteración mejora ~75% combinando el AOT cache de clases perfiladas con el código nativo precompilado.

Cómo funciona la compilación ahead-of-time de HotSpot

El flujo operativo es deliberadamente conservador: no cambia código de aplicación, librerías ni frameworks ni exige una configuración distinta a pedir que se use el AOT cache. La caché es compatible con los recolectores Serial, Parallel, G1 y ZGC, y soporta arquitecturas AArch64 y x64.

El comando de entrenamiento sigue el patrón que ya existía:

java -XX:AOTCacheOutput=app.aot -cp app.jar com.example.App

El archivo app.aot resultante pasa a contener tres cosas a la vez: clases cargadas y enlazadas (gracias a JEP 483), perfiles de ejecución (gracias a JEP 515) y ahora código nativo optimizado de los métodos calientes. En producción, basta con:

java -XX:AOTCache=app.aot -cp app.jar com.example.App

Si el workload cambia, HotSpot aplica deoptimización y reoptimización JIT como siempre; la transición entre código AOT y código JIT es invisible para la aplicación. En palabras del propio JEP, se obtiene "lo mejor de ambos mundos": arranque rápido y sostenido ante cargas variables.

Diferencias técnicas entre código AOT y código JIT

El JEP documenta dos diferencias relevantes que todo equipo debe entender antes de medir en producción:

• Inicialización de clases. Como el orden de inicialización puede variar entre training y producción, el compilador C2 genera dos versiones de cada método AOT que accede a un static field o invoca un static method: una lenta, que garantiza la inicialización de la clase referenciada, y una rápida, más optimizada. HotSpot arranca con la lenta y conmuta a la rápida cuando todas las clases referenciadas están inicializadas.
• Constantes en static final. En compilación JIT, el campo ya está inicializado y C2 puede embeberlo como constante; en compilación AOT todavía no, así que el método tiene que recargarlo. Cuando esto degrada la optimización, el JIT puede regenerar código en runtime.

Ninguna de las dos situaciones rompe la aplicación, pero conviene saber que existen para no malinterpretar benchmarks de un solo arranque.

Restricciones de la AOT cache: cuando se invalida

La AOT cache con código AOT exige tres condiciones adicionales para usarse. Si fallan, HotSpot imprime un aviso y cae al camino clásico (intérprete + JIT), conservando aún las clases pre-cargadas y los perfiles:

1. Misma arquitectura y mismas extensiones de CPU. Código generado para x64 con AVX-512 no funcionará en un x64 sin esa feature set.
2. Mismo garbage collector. El código AOT contiene read/write barriers específicos de cada GC.
3. Restricciones heredadas de JEP 483 sobre similitud entre training y producción.

Para forzar el uso de la caché se introduce -XX:AOTMode=required (renombrado desde AOTMode=on), que falla ruidosamente si hay una violación. El diagnóstico inverso, -XX:-AOTCodeCaching, permite desactivar el código AOT dejando el resto del AOT cache funcional — útil para medir el coste incremental del código compilado.

Observabilidad: qué tocar antes de desplegar

La propuesta añade a PrintCompilation el reporte de carga de código AOT además de la compilación JIT habitual. Combinado con JDK_AOT_VM_OPTIONS, se puede aislar la actividad AOT de la JIT y entender cuánto se está sirviendo realmente desde caché.

Dos detalles operativos que importan al SRE:

• AOTMode=record + AOTConfiguration=app.aotconf separa la fase de captura de la fase de ensamblado (AOTMode=create). Esto permite entrenar con cargas representativas y, en CI, regenerar la caché cuando cambien dependencias o extensiones.
• La opción AOTCodeCaching=off permite medir el peso de la caché en disco: el JEP advierte que el código AOT puede inflar el archivo significativamente. Hay que planificar espacio y tiempo de carga de la caché al dimensionar imágenes contenedor.

El ecosistema ya está reaccionando: Quarkus y Semeru AOT

La pieza no llega sola. Quarkus 3.35 (mayo de 2026) ya integró soporte para IBM Semeru AOT aprovechando la base de Project Leyden que Quarkus 3.32 había introducido. En pruebas internas del equipo de Quarkus sobre el quickstart rest-json, el arranque bajó de unos 380 ms a unos 190 ms con Semeru Runtime Open Edition 25 — una mejora cercana al 50%, en el mismo orden de magnitud que la que mide el JEP 544 sobre HotSpot. La misma release añadió JAR tree-shaking (eliminación de clases inalcanzables en build time, recortes del 39,5% en un caso medido) y PGO para builds nativos en GraalVM, según reportó ADTMag.

Es decir: mientras JEP 544 cierra el círculo en HotSpot, los frameworks cloud-native de Java ya tienen piezas compatibles listas para beneficiarse. La trayectoria combina el tree-shaking de Quarkus, el AOT de Leyden y el PGO de GraalVM en una sola línea: menos clases, pre-cargadas, pre-perfiladas y pre-compiladas.

Qué significa esto para tu startup

1. Mide la warmup penalty de tu servicio Java antes de migrar. Si tu SLA depende de p99 en los primeros 60 segundos tras un deploy o un autoscaling event, corre el AOT cache de JEP 544 contra el patrón actual. El JEP reporta recortes de arranque del 65–80% en cinco marcos populares; ese porcentaje se traduce directamente en menos cold starts, menos timeouts y menos consumo de CPU durante la rampa.
2. Versiona el AOT cache como artefacto de build. Aprovecha el flujo en dos pasos (AOTMode=record + AOTMode=create) en tu pipeline CI. La caché debe viajar acoplada al binario, al runtime y al set de extensiones de CPU del clúster destino; cualquier divergencia degrada el código AOT y termina sirviendo las clases y perfiles de JEP 483/JEP 515, que siguen acelerando aunque el código nativo se regenere.
3. Cuidado con imágenes contenedor políglotas. HotSpot exigirá misma arquitectura, mismo GC y misma feature set de CPU entre training y producción. Si despliegas en pools heterogéneos (instancias ARM junto a x64, o nodos con/sin AVX-512), mantén AOT caches separadas por segmento o desactiva AOTCodeCaching en los nodos no compatibles para no cargar archivos que se rechazarán en arranque.

Fuentes

• JEP 544: Ahead-of-Time Code Compilation
• Quarkus 3.35 Adds JAR Tree-Shaking, Native-Build Optimization, and Semeru AOT Support