streamalism.org

1. Introduksjon

I denne opplæringen skal vi ta en rask titt på og lære om JVMs kodebufferminne.

2. Hva er kodebufferen?

For å si det enkelt, JVM Code Cache er et område der JVM lagrer bytekoden som er samlet i innfødt kode. Vi kaller hver blokk av den kjørbare innfødte koden a nmetode. De nmetode kan være en komplett eller innebygd Java-metode.

Just-in-time (JIT) kompilatoren er den største forbrukeren av kodebufferområdet. Det er grunnen til at noen utviklere kaller dette minnet en JIT-kodebuffer.

3. Code Cache Tuning

Kodebufferen har en fast størrelse. Når den er full, vil JVM ikke kompilere noen tilleggskode ettersom JIT-kompilatoren nå er slått av. Videre vil vi motta “CodeCache er full… Kompilatoren er deaktivert”Advarsel. Som et resultat vil vi ende opp med svekket ytelse i applikasjonen vår. For å unngå dette kan vi stille inn kodebufferen med følgende størrelsesalternativer:

• InitialCodeCacheSize - den opprinnelige kodebufferstørrelsen, 160K standard
• ReservedCodeCacheSize - standard maksimal størrelse er 48 MB
• CodeCacheExpansionSize - utvidelsesstørrelsen på kodebufferen, 32KB eller 64KB

Øker ReservedCodeCacheSize kan være en løsning, men dette er vanligvis bare en midlertidig løsning.

Heldigvis tilbyr JVM en UseCodeCacheFlushing alternativet for å kontrollere spyling av kodebufferområdet. Standardverdien er falsk. Når vi aktiverer det, det frigjør okkupert område når følgende betingelser er oppfylt:

• kodebufferen er full; dette området skylles ut hvis størrelsen overstiger en viss terskel
• det bestemte intervallet er passert siden forrige opprydding
• den forhåndskompilerte koden er ikke varm nok. For hver kompilerte metode holder JVM oversikt over en spesiell varmhetsteller. Hvis verdien på denne telleren er mindre enn en beregnet terskel, frigjør JVM denne delen av forhåndskompilert kode

4. Kodebufferbruk

For å overvåke bruken av kodebuffer, må vi spore størrelsen på minnet som er i bruk.

For å få informasjon om bruk av kodebuffer, kan vi spesifisere –XX: + PrintCodeCache JVM-alternativ. Etter å ha kjørt applikasjonen, ser vi en lignende utgang:

CodeCache: størrelse = 32768Kb brukt = 542Kb max_used = 542Kb ledig = 32226Kb 

La oss se hva hver av disse verdiene betyr:

• størrelse i utgangen viser maksimal størrelse på minnet, som er identisk med ReservedCodeCacheSize
• brukt er den faktiske størrelsen på minnet som for øyeblikket er i bruk
• max_used er den maksimale størrelsen som har vært i bruk
• gratis er det gjenværende minnet som ikke er opptatt ennå

De PrintCodeCache alternativet er veldig nyttig, som vi kan:

• se når spylingen skjer
• avgjøre om vi nådde et kritisk minnebrukspunkt

5. Segmentert kodebuffer

Fra og med Java 9 deler JVM kodebufferen i tre forskjellige segmenter som hver inneholder en bestemt type kompilert kode. For å være mer spesifikk, er det tre segmenter:

• Det ikke-metodesegmentet inneholder JVM intern relatert kode, for eksempel bytecode-tolk. Som standard er dette segmentet rundt 5 MB. Det er også mulig å konfigurere segmentstørrelsen via -XX: NonNMethodCodeHeapSize innstillingsflagg
• Profilkodesegmentet inneholder lett optimalisert kode med potensielt korte levetider. Selv om segmentstørrelsen er rundt 122 MB som standard, kan vi endre den via -XX: ProfiledCodeHeapSize innstillingsflagg
• Det ikke-profilerte segmentet inneholder fullt optimalisert kode med potensielt lange levetider. Tilsvarende er det rundt 122 MB som standard. Denne verdien kan selvfølgelig konfigureres via -XX: NonProfiledCodeHeapSize innstillingsflagg

Denne nye strukturen behandler forskjellige typer overholdt kode annerledes, noe som fører til bedre total ytelse.

For eksempel, å skille kortvarig kompilert kode fra langvarig kode forbedrer metoden feieytelse - hovedsakelig fordi den trenger å skanne et mindre område av minnet.

6. Konklusjon

Denne raske artikkelen presenterer en kort introduksjon til JVM Code Cache.

I tillegg presenterte vi noen bruks- og justeringsalternativer for å overvåke og diagnostisere dette minneområdet.