Hotspot

Hotspot
Grunnleggende data

Vedlikeholder Oracle
utvikler Oracle
Forlagsår 1999
Gjeldende  versjon 22
(12. desember 2011)
operativsystem kryssplattform
programmeringsspråk C / C ++
kategori Java Virtual Machine
Tillatelse GNU General Public License
Nettsted om Suns OpenJDK HotSpot

HotSpot er en mye brukt Java Virtual Machine fra Oracle (tidligere fra Sun Microsystems ) for arbeidsstasjoner og servere , publisert under navnet Java HotSpot Performance Engine . Den er basert på teknikker som just-in-time kompilering og adaptiv optimalisering for å forbedre programvarens kjøretid under kjøring.

Opprinnelseshistorie

Opprinnelsen til HotSpot går tilbake til en gruppe programmerere som jobbet med selvprogrammeringsspråket på Sun Microsystems på begynnelsen av 1990-tallet . Disse programmørene Lars Bak , Gilad Bracha , Steffen Grarup , David Griswold , Robert Griesemer og Urs Hölzle forlot Sun i 1994 og grunnla sammen et selskap kalt Longview Technologies , som også dukket opp under navnet Animorphic Systems , for å eventuelt kunne bruke Smalltalk (programmeringsspråk) basert der Utvikling av Strongtalk-types programmeringsspråk . Der lyktes Urs Hölzle i å utvikle en type tilbakemeldings kompilator, og Strongtalk VM gjorde også store fremskritt. På grunn av den raske utviklingen av det nye Java- programmeringsspråket som ble gitt ut av Sun, ble det besluttet å utvikle en fundamentalt ny Java Virtual Machine . I løpet av denne tiden ble Srdjan Mitrovic akseptert, som tok seg av integrasjonen av Java i den nye VM. I 1997 kjøpte Sun Longview Technologies og Lars Bak ble Suns ledende ingeniør på Hotspot VM. På tidspunktet for overtakelsen var HotSpot omtrent dobbelt så rask som JVM-ene på markedet den gangen. Sun Microsystems ble på sin side kjøpt opp av Oracle i 2010 .

oversikt

Sun Java Server (også Opto eller C2) kompilator konverterer Java- bykoden til Java Virtual Machine (JVM) til kjørbar maskinkode for den tilsvarende målplattformen. Det er en svært optimaliserende just-in-time kompilator (JIT). I motsetning til kompilatorer på forhånd som GCC, genererer just-in-time kompilatorer bare maskinkoden når programmet kjører. I tillegg til den faktiske kjøretiden til programmet, har selve kompileringsprosessen en innvirkning i form av CPU- sykluser og lengre kjøretid. Siden denne (kompilering) prosessen bare brukes adaptivt, dvs. med noen metoder (såkalte hotspots), er denne innsatsen engangs, og spesielt for langvarige serverapplikasjoner veldig kort i forhold til programutførelsestiden, skyldes denne ekstra innsatsen raskt den høyere kvaliteten av den genererte maskinkoden kompensert. I tillegg gjøres kompilering på en egen tråd , som på SMP- maskiner vanligvis kjører på en egen CPU.

I begynnelsen av kjøretiden til et Java- program tolkes hele bytekoden bare. Dette skjer i en tolkesløyfe som behandler bytekode for bytekode. Spesialiteten til hotspot-kompilatorer er at de bare oversetter ofte brukte kodeseksjoner - såkalte "hotspots" - til maskinkode . Hotspots oppdages også lokalt, dvs. innenfor metoder, men den minste kompilasjonsenheten er alltid metoden. Siden oversettelsen bare foregår med spesielt ofte brukte eller langvarige metoder og ikke med hele koden, er den ekstra innsatsen, spesielt for langvarige applikasjoner, ubetydelig.

Fordelen med denne prosedyren ligger i muligheten for å utføre lukkede verdensoptimaliseringer samt å bruke dynamiske optimaliseringer . Dette betyr at JVM alltid kjenner hele den lastede bytekoden og kan bruke den til å ta optimaliseringsbeslutninger som endrer semantikken til koden slik at den bare fungerer riktig under de eksisterende bruksbetingelsene. Hvis kode lastes inn ved kjøretid som endrer disse driftsforholdene, utfører (server) hotspot VM en de-optimalisering - og garanterer dermed riktig funksjon ved å fjerne og re-optimalisere koden som er for aggressivt optimalisert for denne bruken.

Kompileringsprosessen til Sun hotspot kompilatoren består av følgende trinn:

Oppdagelse av hotspot, kompiler policy

Den grunnleggende prosedyren, hvordan og under hvilke omstendigheter en metode kompileres, er definert i Sun JVM av såkalte kompileringspolitikker . Disse retningslinjene, modellert i et C ++ -klassehierarki, StackWalkCompPolicylagres i klassen når det gjelder serverkompilatoren . Sammensetningsprosessen kan dermed konfigureres på nytt ved å endre eller tilpasse retningslinjene. I praksis skjer dette imidlertid relativt sjelden, bortsett fra å sette flagget -XX:+CompileTheWorldfor å oversette bokstavelig talt alle metoder. Navnet StackWalkCompPolicy går tilbake til algoritmen for å sjekke anropstakken til metodene som skal undersøkes oppover til den første metoden blir oppdaget som ikke lenger vil føre til inline.

I serverkompilatoren brukes to terskelverdier for å identifisere hotspots:

Hyppighet for å ringe en metode
Denne terskelverdien holdes i den JVM-interne variabelen CompileThreshold og har forskjellige grunnleggende innstillinger på de forskjellige plattformene. På Intel 386-arkitekturen er det 10 000 metodeanrop for serveren JVM og 1500 for klienten JVM.
Antall løkker i en metode
Hvis løkker i metoder utføres for ofte, markerer dette også en metode for kompilering. Frekvensen til en sløyfekjøring telles i sin tur individuelt i såkalte backedge tellere for hver sløyfe.

Det er allerede bestemmelser i serverkompilatoren for å støtte såkalt to-lags kompilering i senere versjoner. Målet er å først kompilere en metode raskt og uten massiv optimalisering og senere (eller parallelt) å oversette den på en svært optimalisert måte i et videre løp. Denne “to lags samling” vil føre til en sammenslåing av server og klient kompilatoren .

Samling

Etter at policy-kontrollen har markert individuelle metoder for kompilering, opprettes et CompileTaskobjekt for hver av metodene og plasseres i CompileQueue. Det, så vel som den andre kontrollen av hele oversettelsesprosessen, er ansvaret for CompileBroker. Dette genererer de individuelle oversettingsjobbene ( CompileTask), setter dem i køen og våkner til slutt med en notify()inaktiv kompileringstråd. Antallet kompileringsvalgene tråder er vanligvis log (antall CPU), men i det minste to. Ulike PerfCountergjenstander holdes også i CompileBroker , som kan brukes til påfølgende ytelsesovervåking eller visning.

Nå konverteres bytekoden i forskjellige faser. De viktigste trinnene er:

  • Analyse av byte-koden
  • Slette ubrukte noder ( noder )
  • Velge instruksjonene.
  • Global verdi nummerering (GVN)
  • Generer kontrollflytdiagram (CFG)
  • Tildelingsfanen ( Chaitin Graph Coloring )
  • Optimalisering av kikkhull

Den interne representasjonen (IR) av programkjøringen lagres i SSA- format.

optimalisering

Blant annet ved å lagre nodegrafen i SSA-format er det mulig å bruke en rekke optimaliseringsmetoder. Her er de viktigste:

Innfelling
Korte metoder (maksimalt 35 byte ) settes inn i innringerkroppen i stedet for å bli hoppet til. Innlining er ikke lønnsomt med lengre metoder.
Loop utrulling
Korte sløyfer er "utrullet", så å si, det vil si at de enkelte sløyfepasseringene behandles sekvensielt uten å hoppe tilbake. I likhet med inlining øker dette minneforbruket, men med noen få sløyfer er det billigere enn å teste en hopptilstand konstant.
Død kode eliminering
Ubrukte instruksjoner blir oppdaget og kastet på bytekodenivå. Selv om denne optimaliseringen på kildekodenivået av Java Frontend Compiler (javac) brukes mye mer, brukes dette trinnet også på bytecode-nivå.
Optimalisering av kikkhull
Optimalisering på monteringsnivå. Her genereres en kontekst ( kikkehull ) ved å bruke noen få monteringsinstruksjoner, og for eksempel elimineres overflødige minnetilganger og registertilganger optimaliseres.

Kodegenerering, aktivering

AD-filer

Systemets kodegenerator (emitter) genererer maskinkode på grunnlag av prefabrikkerte maler som lagrer delekodeseksjonene som tilsvarer bytekoden i såkalte Architecture Description Files (AD-filer). I disse filene er de forskjellige CPU-ene beskrevet abstrakt med assembler-kommandoer, adresseringsmodi og spesielt antall og bredde på registerene. AD-filene blir oversatt til C ++ klasser ved hjelp av en spesiell forprosessor, som er innlemmet i VM-byggeprosessen.

CompileCache

Monteringsspråkinstruksjonene opprettet av kompilatoren lagres i CompilerCachemed en referanse til den opprinnelige bykoden. Dette er nødvendig for å kunne få tilgang til bytekoden igjen under en senere de-optimalisering. Deoptimering kan være nødvendig hvis for eksempel dynamisk belastede klasser der individuelle metoder er innebygd ( inline ) erstattes av nye ved kjøretid.

Stubber

Maskinkoden generert av kompileringsprosessen kan ikke fungere uten å bruke tjenestene til VM. I en metode, for eksempel, må et navnesøk utføres i symboltabellen, en referanse må løses eller andre JVM-tjenester må brukes. Derfor settes såkalte stubber gjentatte ganger inn i maskinkoden , hvor den kompilerte koden tar kontakt med omverdenen.

Aktiver samlingen

I prinsippet kan den fullførte metoden enten byttes ut ved kjøring av bytekoden eller brukes på tidspunktet for neste samtale. Å avbryte en kjøremetode og erstatte den med den kompilerte versjonen kalles on-stack replacement (OSR). For å oppnå denne svært dynamiske operasjonen blir såkalte lagringspunkter satt inn i bytekoden. Den virtuelle maskinen er i en definert, synkronisert tilstand ved disse lagringspunktene . Nå byttes bytekoden ut for kompilering, og den nøyaktige tilsvarende CPU-stakken genereres syntetisk.

litteratur

  • Michael Paleczny, Christopher Vick, Cliff Click: The Java HotSpot server compiler . I: Proceedings of the Java Virtual Machine Research and Technology Symposium on Java Virtual Machine Research and Technology Symposium - Volum 1 . USENIX Association, Monterey, California 2001 ( acm.org ).
  • Alfred V. Aho, Ravi Sethi, Jeffrey D. Ullman: Kompilator. Prinsipper, teknikker og verktøy. Addison-Wesley, Reading 1988, ISBN 0-201-10194-7 ("Dragon Book").

hovne opp

  1. ↑ web.archive.org . 27. april 1999 (åpnet 2. november 2013).
  2. ^ Java HotSpot Performance Engine Architecture. Hentet 9. juni 2020 .
  3. ^ The History of the Strongtalk Project av Dave Griswold.
  4. ↑ Sun kjøper Java kompilator teknologi basert på Self !!! Keith Hankin 18. februar 1997
  5. ↑ Ingeniører som gir viktige bidrag til Suns Java-plattform ( Memento fra 20. april 1999 i Internet Archive ), Mountain View 18. februar 1997
  6. ↑ Google 'Crankshaft' inspirert av Sun Java HotSpot - Bak to 'adaptive compilation' av Cade Metz, 9. desember 2010
  7. ↑ Språkbaserte virtuelle maskiner ... eller hvorfor hastighet betyr noe ( Minne til originalen fra 23. september 2015 i Internett-arkivet ) Info: Arkivkoblingen ble satt inn automatisk og har ennå ikke blitt sjekket. Vennligst sjekk originalen og arkivlenken i henhold til instruksjonene, og fjern deretter denne meldingen. av Lars Bak  @1@ 2Mal: Webachiv / IABot / www.aosd.net

weblenker