Compromisos de la imagen nativa

La imagen nativa es potente, pero no gratuita. Cambia la adaptabilidad de la JVM en tiempo de ejecución por un arranque rápido y un bajo consumo de memoria. Comprender estas ventajas y desventajas le ayuda a decidir cuándo conviene usar código nativo.

Es la principal ventaja. Un binario nativo omite la carga de clases, la verificación del bytecode y el calentamiento del JIT. Puede iniciarse en unos pocos milisegundos, frente a los cientos de milisegundos de una JVM; esto supone un cambio decisivo para las CLI y las funciones sin servidor.

La ausencia de un compilador JIT y de estructuras de perfilado, junto con un heap de imagen precomputado, hace que un proceso nativo use mucha menos RAM. Esto permite empaquetar más instancias por contenedor y reducir la capacidad de forma agresiva.

La disyuntiva fundamental. El JIT optimiza usando perfiles de ejecución activos, por lo que una JVM de larga duración puede alcanzar un rendimiento máximo superior al de un binario AOT optimizado a ciegas durante la compilación. Para cargas de trabajo intensivas y sostenidas, la JVM puede seguir siendo superior.

GraalVM reduce la brecha de rendimiento mediante PGO: construya una imagen instrumentada, ejecute una carga de trabajo representativa para recopilar perfiles y vuelva a compilar usando esos perfiles. El binario AOT se parecerá entonces a un JIT ya calentado para esa carga de trabajo.

Compilar una imagen nativa es lento y consume mucha memoria: las aplicaciones grandes pueden requerir minutos de CPU y gigabytes de RAM. Esto alarga las canalizaciones de CI en comparación con una compilación rápida de jar.

La reflexión, los proxies y los recursos requieren metadatos, como se explicó antes. El código que depende en gran medida de la carga de clases en tiempo de ejecución o de la generación de bytecode puede ser difícil, o incluso imposible, de convertir completamente en nativo sin realizar cambios.

Algunas herramientas de la JVM funcionan de forma diferente en modo nativo. Los agentes JVMTI estándar y ciertos perfiladores no se conectan de la misma manera; en su lugar, se utilizan herramientas de monitorización o muestreo específicas de native-image. Planifique su estrategia de observabilidad en consecuencia.

Native image incluye sus propios recolectores de basura (un Serial GC sencillo y G1 en algunas ediciones). Para heaps muy grandes, toda la gama de GC de la JVM puede ofrecer una latencia mejor. Elija el GC según el tamaño del heap de su carga de trabajo y los requisitos de pausa.

• Funciones serverless que escalan hasta cero.
• Herramientas CLI en las que el tiempo de inicio es determinante.
• Microservicios en contenedores muy densos.
• Trabajos por lotes de corta duración.

• Servicios de larga duración y críticos para el rendimiento, donde importa el rendimiento máximo del JIT.
• Aplicaciones con mucha carga dinámica de clases o generación de bytecode.
• Cargas de trabajo que dependen de herramientas basadas en JVMTI.

Compruebe su comprensión de las ventajas y desventajas de las imágenes nativas.

Ha sopesado las ventajas y desventajas de las imágenes nativas:

• Ventajas: inicio en milisegundos y una huella de memoria reducida.
• Costes: rendimiento máximo potencialmente inferior, compilaciones lentas, metadatos para características dinámicas y diferencias en las herramientas.
• PGO reduce la brecha de rendimiento mediante recompilaciones guiadas por perfiles.
• Native Image es adecuado para CLIs, entornos serverless y microservicios densamente empaquetados.
• La JVM es adecuada para aplicaciones de larga duración, críticas para el rendimiento y con muchas características dinámicas.