Compromessi della native image

L'immagine nativa è potente, ma non è gratuita. Scambia l'adattabilità a runtime della JVM con un avvio rapido e un basso consumo di memoria. Comprendere questi compromessi vi aiuta a decidere quando scegliere l'esecuzione nativa.

Il vantaggio principale. Un binario nativo evita il caricamento delle classi, la verifica del bytecode e il riscaldamento del JIT. Può avviarsi in pochi millisecondi anziché in centinaia per una JVM, con un effetto decisivo sulle CLI e sulle funzioni serverless.

La mancanza di un compilatore JIT e di strutture per il profiling, insieme a un image heap precalcolato, fa sì che un processo nativo utilizzi molta meno RAM. È così possibile eseguire più istanze per container e ridimensionare in modo aggressivo.

Questo è il compromesso cruciale. Il JIT ottimizza usando i profili di runtime effettivi, quindi una JVM di lunga durata può raggiungere un throughput di picco superiore a quello di un binario AOT ottimizzato alla cieca durante la build. Per carichi di lavoro intensivi e prolungati, la JVM potrebbe comunque risultare superiore.

GraalVM riduce il divario di throughput con la PGO: si crea un'immagine strumentata, si esegue un carico di lavoro rappresentativo per raccogliere i profili, quindi si ricompila usando quei profili. Il binario AOT risultante assomiglia così a un JIT già riscaldato per quel carico di lavoro.

La creazione di un'immagine nativa è lenta e richiede molta memoria: per le applicazioni di grandi dimensioni possono servire minuti di CPU e gigabyte di RAM. Rispetto a una rapida build di jar, questo allunga le pipeline CI.

La reflection, i proxy e le risorse richiedono metadati, come illustrato in precedenza. Il codice che fa ampio affidamento sul caricamento delle classi a runtime o sulla generazione di bytecode può essere difficile, o persino impossibile, da rendere completamente nativo senza modificarlo.

Alcuni strumenti della JVM si comportano diversamente in modalità nativa. Gli agenti JVMTI standard e alcuni profiler non si collegano allo stesso modo; al loro posto si usano strumenti di monitoraggio o campionamento specifici di native-image. È quindi opportuno pianificare di conseguenza la strategia di osservabilità.

Native Image include i propri GC, ovvero un semplice Serial GC e G1 in alcune edizioni. Per gli heap molto grandi, l'intero insieme di GC della JVM può offrire una latenza migliore. È importante scegliere il GC in base alle dimensioni dell'heap del carico di lavoro e ai requisiti relativi alle pause.

• Funzioni serverless che possono scalare fino a zero.
• Strumenti CLI in cui il tempo di avvio è determinante.
• Microservizi in container densamente impacchettati.
• Job batch di breve durata.

• Servizi di lunga durata e con throughput critico, in cui sono importanti le prestazioni di picco del JIT.
• Applicazioni con un uso intenso del caricamento dinamico delle classi o della generazione di bytecode.
• Carichi di lavoro che dipendono da strumenti basati su JVMTI.

Verifichi la Sua comprensione dei compromessi delle immagini native.

Ha valutato i compromessi delle immagini native:

• Vantaggi: avvio in millisecondi e ingombro ridotto in memoria.
• Costi: throughput di picco potenzialmente inferiore, build lente, metadati per le funzionalità dinamiche e differenze negli strumenti.
• La PGO riduce il divario di throughput attraverso ricompilazioni guidate dai profili.
• Le immagini native sono adatte a CLI, applicazioni serverless e microservizi densamente impacchettati.
• La JVM è adatta ad applicazioni di lunga durata, con throughput critico e un uso intenso delle funzionalità dinamiche.