Avveininger ved native image

Native Image er kraftig, men ikke gratis. Det bytter JVM-ens tilpasningsevne under kjøring mot rask oppstart og lavt minneforbruk. Når du forstår avveiningene, blir det lettere å avgjøre når det er riktig å gå native.

Dette er den viktigste fordelen. En native-binærfil hopper over klasselasting, bytekodeverifisering og JIT-oppvarming. Den kan starte på noen få millisekunder, sammenlignet med hundrevis ved oppstart av en JVM – en stor fordel for CLI-verktøy og serverløse funksjoner.

Ingen JIT-kompilator, ingen profileringsstrukturer og en forhåndsberegnet image-heap gjør at en native prosess bruker langt mindre RAM. Dette lar Dem kjøre flere instanser per container og skalere kraftig ned.

Dette er den avgjørende avveiningen. JIT optimaliserer ved hjelp av aktive runtime-profiler, så en JVM som kjører lenge, kan oppnå høyere maksimal gjennomstrømming enn en AOT-binærfil som ble optimalisert uten slik informasjon under byggingen. For langvarige, intensive arbeidsbelastninger kan JVM-en fortsatt vinne.

GraalVM reduserer forskjellen i gjennomstrømming med PGO: bygg et instrumentert image, kjør en representativ arbeidsbelastning for å samle inn profiler, og bygg deretter på nytt ved hjelp av disse profilene. AOT-binærfilen ligner da på en oppvarmet JIT for denne arbeidsbelastningen.

Det er langsomt og minnekrevende å bygge et native image — store apper kan bruke flere minutter med CPU-tid og gigabytes med RAM. Dette forlenger CI-pipelinesammenlignet med en rask jar-bygging.

Refleksjon, proxyer og ressurser krever metadata, som omtalt tidligere. Kode som i stor grad er avhengig av dynamisk klasselasting eller generering av bytekode, kan være vanskelig eller umulig å gjøre fullt native uten endringer.

Noen JVM-verktøy fungerer annerledes i native-modus. Standard JVMTI-agenter og enkelte profilere kobler seg ikke til på samme måte; i stedet bruker De overvåking eller sampling som er spesifikk for native-image. Planlegg strategien for observerbarhet deretter.

Native image leveres med egne GC-er (en enkel Serial GC og G1 i enkelte utgaver). For svært store heaps kan JVM-ens komplette utvalg av GC-er gi bedre latenstid. Tilpass GC-en til heap-størrelsen og kravene til pauser i arbeidsbelastningen.

• Serverless-funksjoner som skalerer ned til null.
• CLI-verktøy der oppstartstiden er avgjørende.
• Mikrotjenester i tettpakkede containere.
• Kortvarige batchjobber.

• Langvarige, gjennomstrømmingskritiske tjenester der maksimal JIT-ytelse er viktig.
• Apper med omfattende dynamisk klasselasting eller generering av bytekode.
• Arbeidsbelastninger som er avhengige av verktøy basert på JVMTI.

De har vurdert avveiningene ved native image:

• Fordeler: oppstart på millisekunder og lavt minneavtrykk.
• Kostnader: potensielt lavere maksimal gjennomstrømming, langsomme bygginger, metadata for dynamiske funksjoner og forskjeller i verktøystøtte.
• PGO reduserer forskjellen i gjennomstrømming gjennom profilstyrte ombygginger.
• Native passer for CLI-verktøy, serverless og tettpakkede mikrotjenester.
• JVM passer for langvarige, gjennomstrømmingskritiske og dynamikktunge apper.