JVM Garbage Collection Basics

Garbage Collectors Algoritmes

Garbage Collectors hebben meestal de volgende doelen (makkelijker gezegd dan gedaan)

  • Zeer korte “stop de wereld pauzes” met een doel van een paar milliseconden
  • Pauzetijden nemen niet toe met een heap, live-set, of root-set size
  • Om heap sizes variërend van enkele MB’s tot vele TB’s aan te kunnen
  • Hoge concurrency – Al het zware werk wordt gedaan terwijl Java-threads doorgaan met uitvoeren
  • Hoge throughput
  • Gemakkelijk af te stellen

Garbage Collectors

Gegevens in de heap worden gepartitioneerd in meerdere toewijzingsregio’s (of generaties) die gescheiden worden gehouden op basis van de objectleeftijd (d.w.z.d.w.z. het aantal overleefde GC-iteraties). Terwijl sommige collectors uni-generationeel zijn, gebruiken de anderen twee generaties: (1) de Jonge Generatie (verder opgesplitst in Eden en twee Survivor regio’s) en (2) de Oude (of Tenured) Generatie.
Bron: Blog door Ionut Balosin

Twee generatie collectors:

Serial GC – Dit algoritme gebruikt een enkele thread om alle garbage collection-werkzaamheden uit te voeren, waardoor het relatief efficiënt is omdat er geen communicatie-overhead tussen threads is. Het is het meest geschikt voor machines met één processor, omdat het geen voordeel kan halen uit multiprocessor-hardware.

Throughput (Parallel) GC – Dit algoritme gebruikt mark-copy in de Jonge generatie en mark-sweep-compact in de Oude generatie. Zowel de Young als de Old collections triggeren stop-the-world events, waarbij alle applicatie-threads worden gestopt om de garbage collection uit te voeren. Beide verzamelaars voeren de markering- en kopieer-/compacteerfasen uit met behulp van meerdere threads, vandaar de naam ‘Parallel’.

Parallel Garbage Collector is geschikt voor multi-core machines in gevallen waarin je primaire doel is om de verwerkingscapaciteit te verhogen. Hogere doorvoer wordt bereikt door efficiënter gebruik van systeembronnen:

  • tijdens het verzamelen ruimen alle kernen de vuilnis parallel op, wat resulteert in kortere pauzes
  • tussen vuilnisverzamelcycli verbruikt geen van de verzamelaars bronnen

Garbage First (G1) GC – Deze verzamelaar is een server-stijl vuilnisverzamelaar, bedoeld voor multi-processor machines met grote geheugens. Het voldoet aan garbage collection (GC) pauzetijd doelstellingen met een hoge waarschijnlijkheid, terwijl het bereiken van een hoge verwerkingscapaciteit.

  • De G1 verzamelaar neemt een andere aanpak in termen van heap geheugen model. De heap wordt gepartitioneerd in een set van heap-regio’s van gelijke grootte, elk een aaneengesloten bereik van virtueel geheugen.
  • Aan bepaalde regiosets worden dezelfde rollen (eden, survivor, old) toegekend als in de oudere verzamelaars, maar er is geen vaste grootte voor.
  • De regiogrootte wordt gekozen door de JVM bij het opstarten. De JVM richt zich over het algemeen op ongeveer 2000 regio’s, variërend in grootte van 1 tot 32Mb. De G1-collector hanteert een andere aanpak

Voor meer details, zie Aan de slag met de G1 GC

G1 Heap Allocation

Uni generationele collectors:

Shenandoah GC – Shenandoah is de vuilnisman met een lage pauzetijd die de pauzetijden van GC verkort door meer vuilnisophaalwerk gelijktijdig met het lopende Java-programma uit te voeren. Shenandoah doet het grootste deel van het GC-werk gelijktijdig, inclusief de gelijktijdige verdichting, wat betekent dat de pauzetijden niet langer recht evenredig zijn met de grootte van de heap. Garbage collecting van een 200 GB heap of een 2 GB heap zou een vergelijkbaar laag pauzegedrag moeten hebben.

Voor meer details, zie Implementatiedetails in Wiki

Z GC – ZGC is een concurrent, single-generatie, regio-gebaseerde, NUMA-bewuste, comprimerende collector. Stop-de-wereld fases zijn beperkt tot root scanning, dus GC pauzetijden nemen niet toe met de grootte van de heap of de live set.

Voor meer details, zie Sessie over ZGC door Per Liden op YouTube

Finitief,

Epsilon GC (experimenteel)- Een GC die geheugentoewijzing afhandelt maar geen echt geheugen terugwinningsmechanisme implementeert. Zodra de beschikbare Java heap is uitgeput, zal de JVM afsluiten. Ontworpen voor interne JDK-tests, maar kan in twee situaties nuttig zijn

  • Zeer kortstondige programma’s
  • Programma’s zijn zorgvuldig geschreven om geheugen te hergebruiken en nooit nieuwe toewijzingen uit te voeren

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.