JVM szemétgyűjtés alapjai

Semétgyűjtők algoritmusai

A szemétgyűjtőknek jellemzően a következő céljai vannak (könnyebb mondani, mint megtenni)

  • Nagyon rövid “megáll a világ szünetek”, cél a néhány ezredmásodperc
  • A szünetidő nem nő a halom, live-set, vagy root-set mérete
  • A néhány MB-tól több TB-ig terjedő heapméretek kezelésére
  • Nagyon magas párhuzamosság – Minden nehéz munkát elvégeznek, miközben a Java szálak tovább futnak
  • Nagy áteresztőképesség
  • .

  • Egyszerűen hangolható

Garbage Collectors

A heapben lévő adatok több allokációs régióra (vagy generációra) vannak felosztva, amelyeket az objektum kora alapján külön tartanak (i.azaz a túlélt GC-iterációk száma alapján). Míg egyes gyűjtők egygenerációsak, addig a többiek két generációt használnak: (1) a Young Generation (tovább osztva Eden és két Survivor régióra) és (2) az Old (vagy Tenured) Generation.
Source: Ionut Balosin blogja

Két generációs gyűjtők:

Serial GC – Az algoritmus egyetlen szálat használ az összes szemétgyűjtési munka elvégzésére, ami viszonylag hatékonnyá teszi, mivel nincs kommunikációs többletköltség a szálak között. Egyprocesszoros gépekhez a legalkalmasabb, mert nem tudja kihasználni a többprocesszoros hardver előnyeit.

Átlépési (párhuzamos) GC – Ez az algoritmus a fiatal generációban mark-copy-t, az öreg generációban pedig mark-sweep-compact-ot használ. Mind a Young, mind a Old gyűjtés stop-the-world eseményeket vált ki, leállítva az összes alkalmazásszálat a szemétgyűjtés elvégzéséhez. Mindkét gyűjtő a jelölési és másolási/tömörítési fázisokat több szál segítségével futtatja, innen a “Parallel” elnevezés.

A Parallel Garbage Collector alkalmas többmagos gépekhez olyan esetekben, amikor az elsődleges cél az áteresztőképesség növelése. A nagyobb áteresztőképesség a rendszer erőforrásainak hatékonyabb kihasználása miatt érhető el:

  • a gyűjtés során minden mag párhuzamosan tisztítja a szemetet, ami rövidebb szüneteket eredményez
  • a szemétgyűjtési ciklusok között egyik gyűjtő sem fogyaszt erőforrást

Garbage First (G1) GC – Ez a gyűjtő egy szerver stílusú szemétgyűjtő, amelyet a nagy memóriával rendelkező többprocesszoros gépekhez céloz meg. Nagy valószínűséggel teljesíti a szemétgyűjtés (GC) szüneteltetési idejére vonatkozó célokat, miközben nagy áteresztőképességet ér el.

  • A G1 gyűjtő más megközelítést alkalmaz a halom memóriamodell tekintetében. A kupacot egyenlő méretű kupacrégiókra particionálja, amelyek mindegyike a virtuális memória egybefüggő tartománya.
  • A régiók egyes halmazai ugyanazokat a szerepeket kapják (eden, survivor, old), mint a régebbi gyűjtőkben, de nincs fix méretük.
  • A régiók méretét a JVM választja ki indításkor. A JVM általában körülbelül 2000 régiót céloz meg, amelyek mérete 1 és 32 Mb között változik. A G1 gyűjtő más megközelítést alkalmaz

További részletekért lásd a Getting Started with the G1 GC

G1 Heap Allocation

Uni generációs gyűjtők:

Shenandoah GC – A Shenandoah az alacsony szünetidejű szemétgyűjtő, amely csökkenti a GC szünetidőt azáltal, hogy több szemétgyűjtési munkát végez a futó Java programmal egyidejűleg. A Shenandoah a GC munka nagy részét egyidejűleg végzi, beleértve az egyidejű tömörítést is, ami azt jelenti, hogy a szünetidők már nem egyenesen arányosak a halom méretével. Egy 200 GB-os heap vagy egy 2 GB-os heap szemétgyűjtése hasonlóan alacsony szüneteltetéssel kell, hogy járjon.

További részletekért lásd a Wiki implementációs részletei

Z GC – A Z GC egy párhuzamos, egygenerációs, régióalapú, NUMA-tudatos, tömörítő gyűjtő. A stop-the-world fázisok a root szkennelésre korlátozódnak, így a GC szünetideje nem növekszik a heap vagy az élőhalmaz méretével.

További részletekért lásd: Session on ZGC by Per Liden on YouTube

Finally,

Epsilon GC (kísérleti)- Egy GC, amely kezeli a memória kiosztását, de nem valósít meg semmilyen tényleges memória-visszavételi mechanizmust. Amint a rendelkezésre álló Java heap kimerül, a JVM leáll. A JDK belső teszteléséhez tervezték, de elképzelhető, hogy két helyzetben hasznos lehet

  • Nagyon rövid életű programok
  • A programok gondosan úgy vannak megírva, hogy újrafelhasználják a memóriát, és soha nem végeznek új allokációt

.

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.