Garbage Collectors Algoritmer
Garbage Collectors har typisk følgende mål (lettere sagt end gjort)
- Meget korte “stop the world pauses” med et mål på få millisekunder
- Pausetider øges ikke med en heap, live-set, eller root-sæt størrelse
- Til håndtering af heap-størrelser fra få MB op til mange TB
- Høj samtidighed – Alt tungt arbejde udføres, mens Java-tråde fortsætter med at udføre
- Højt gennemløb
- Let at tune
Garbage Collectors
Data i heap er opdelt i flere allokeringsregioner (eller generationer), som holdes adskilt baseret på objektets alder (i.dvs. antallet af overlevede GC-iterationer). Mens nogle opsamlere er uni-generationelle, bruger de andre to generationer: (1) den unge generation (yderligere opdelt i Eden-regioner og to overlevende regioner) og (2) den gamle generation (eller Tenured-generation).
Kilde:
To generationsopsamlere:
Serial GC – Algoritmen bruger en enkelt tråd til at udføre alt arbejdet med garbage collection, hvilket gør den relativt effektiv, fordi der ikke er noget kommunikationsoverhead mellem tråde. Den er bedst egnet til enkeltprocessormaskiner, fordi den ikke kan udnytte multiprocessorhardware.
Throughput (Parallel) GC – Denne algoritme anvender mark-copy i den unge generation og mark-sweep-compact i den gamle generation. Både Young- og Old-samlinger udløser stop-the-world-hændelser, der stopper alle applikationstråde for at udføre garbage collection. Begge opsamlere kører markerings- og kopierings-/komprimeringsfaserne ved hjælp af flere tråde, deraf navnet “Parallel”.
Parallel Garbage Collector er velegnet til maskiner med flere kerner i tilfælde, hvor dit primære mål er at øge gennemstrømningen. Højere gennemløb opnås på grund af den mere effektive udnyttelse af systemressourcerne:
- under indsamlingen renser alle kerner skraldet parallelt, hvilket resulterer i kortere pauser
- mellem skraldespandsindsamlingscyklusser bruger ingen af indsamlerne nogen ressourcer
Garbage First (G1) GC – Denne indsamler er en skraldespandsindsamler i serverstil, der er målrettet til multiprocessormaskiner med store hukommelser. Den opfylder målene for garbage collection (GC) pausetid med stor sandsynlighed, samtidig med at den opnår et højt gennemløb.
- G1-opsamleren anvender en anden tilgang med hensyn til heap-hukommelsesmodellen. Heap’en er opdelt i et sæt heap-regioner af samme størrelse, som hver er et sammenhængende område af virtuel hukommelse.
- Visse regionssæt tildeles de samme roller (eden, survivor, old) som i de ældre opsamlere, men der er ikke en fast størrelse for dem.
- Regionens størrelse vælges af JVM’en ved opstart. JVM’en sigter generelt mod ca. 2000 regioner, der varierer i størrelse fra 1 til 32 Mb. G1-opsamleren anvender en anden fremgangsmåde
For flere oplysninger henvises til Kom godt i gang med G1 GC
Uni generationelle opsamlere:
Shenandoah GC – Shenandoah er en skraldesamler med lav pausetid, der reducerer GC-pausetiderne ved at udføre mere skraldesamlingsarbejde samtidig med det kørende Java-program. Shenandoah udfører hovedparten af GC-arbejdet samtidig, herunder den samtidige komprimering, hvilket betyder, at dens pausetider ikke længere er direkte proportionale med størrelsen af heap’en. Skraldeindsamling af en 200 GB heap eller en 2 GB heap bør have en lignende lav pauseadfærd.
For flere detaljer henvises til Implementeringsdetaljer i Wiki
Z GC – ZGC er en samtidig, enkeltgenerations, regionsbaseret, NUMA-bevidst, komprimerende opsamler. stop-the-world-faserne er begrænset til rodscanning, så GC-pausetiderne stiger ikke med størrelsen af heap’en eller live-sættet.
For flere detaljer henvises til Session on ZGC by Per Liden on YouTube
Endeligt,
Epsilon GC (eksperimentel)- En GC, der håndterer hukommelsesallokering, men ikke implementerer nogen egentlig mekanisme til hukommelsestilbagekaldelse. Når den tilgængelige Java-heap er opbrugt, lukker JVM’en ned. Designet til intern JDK-testning, men kan tænkes at være nyttig i to situationer
- Meget kortvarige programmer
- Programmer er omhyggeligt skrevet for at genbruge hukommelse og aldrig foretage nye allokeringer