Algoritmy garbage collectorů
Garbage Collectors mají obvykle následující cíle (snadněji se to řekne, než udělá)
- Velmi krátké „stop the world pauses“ s cílem několika milisekund
- Časy pauz se nezvyšují s hromadou, live-set, nebo root-setu
- Zvládnout velikost haldy od několika MB až po mnoho TB
- Vysoká souběžnost – veškerá těžká práce se provádí, zatímco vlákna Java pokračují v provádění
- Vysoká propustnost
- Snadné ladění
Kolektory odpadu
Data v haldě jsou rozdělena do více alokačních oblastí (nebo generací), které jsou odděleny na základě stáří objektu (tj.tj. počtu přežitých iterací GC). Zatímco některé kolektory jsou jednogenerační, jiné používají dvě generace: (1) Mladá generace (dále rozdělená na Eden a dvě oblasti Survivor) a (2) Stará (neboli Tenured) generace.
Zdroj: Ionut Balosin
Dvě generace kolektorů:
Sériový GC – Algoritmus používá jediné vlákno k provedení všech prací spojených se sběrem odpadu, díky čemuž je relativně efektivní, protože mezi vlákny není žádná komunikační režie. Nejlépe se hodí pro jednoprocesorové stroje, protože nedokáže využít výhody víceprocesorového hardwaru.
Průběžný (paralelní) GC – Tento algoritmus používá mark-copy v mladé generaci a mark-sweep-compact ve staré generaci. Mladá i Stará kolekce vyvolávají události stop-the-world, které zastaví všechna aplikační vlákna, aby se provedl garbage collection. Oba kolektory provádějí fáze označování a kopírování/kompaktování pomocí více vláken, odtud název „paralelní“.
Paralelní sběrač odpadků je vhodný pro vícejádrové stroje v případech, kdy je vaším hlavním cílem zvýšit propustnost. Vyšší propustnosti je dosaženo díky efektivnějšímu využití systémových prostředků:
- během sběru uklízejí všechna jádra odpadky paralelně, což vede ke kratším pauzám
- mezi cykly sběru odpadků žádný z kolektorů nespotřebovává žádné prostředky
Garbage First (G1) GC – Tento kolektor je serverový kolektor odpadků, určený pro víceprocesorové stroje s velkou pamětí. S vysokou pravděpodobností splňuje cíle týkající se doby pauzy pro garbage collection (GC) a zároveň dosahuje vysoké propustnosti.
- Kolektor G1 používá odlišný přístup z hlediska modelu paměti haldy. Hromada je rozdělena na sadu stejně velkých oblastí haldy, z nichž každá představuje souvislý rozsah virtuální paměti.
- Některým sadám oblastí jsou přiřazeny stejné role (eden, survivor, old) jako u starších kolektorů, ale není pro ně stanovena pevná velikost.
- Velikost oblasti je zvolena JVM při spuštění. JVM se obvykle zaměřuje na přibližně 2000 regionů, jejichž velikost se pohybuje od 1 do 32 MB. Kolektor G1 používá jiný přístup
Podrobnější informace naleznete v článku Začínáme s GC G1
Uni generational collectors:
Shenandoah GC – Shenandoah je garbage collector s nízkou dobou pauzy, který zkracuje dobu pauzy GC tím, že provádí více prací garbage collection souběžně s běžícím programem v Javě. Shenandoah provádí většinu práce GC souběžně, včetně souběžného zhušťování, což znamená, že jeho doby pauzy již nejsou přímo úměrné velikosti haldy. Sbírání odpadu na 200GB haldě nebo 2GB haldě by mělo mít podobně nízkou dobu pauzy.
Další podrobnosti naleznete v části Podrobnosti o implementaci ve Wiki
Z GC – ZGC je souběžný, jednogenerační, regionálně založený, NUMA-aware, kompaktující kolektor. Fáze stop-the-world jsou omezeny na kořenové skenování, takže doba pauzy GC se nezvyšuje s velikostí haldy nebo živé sady.
Další podrobnosti naleznete v článku Session on ZGC by Per Liden na YouTube
Nakonec,
Epsilon GC (experimentální)- GC, který zpracovává alokaci paměti, ale neimplementuje žádný skutečný mechanismus rekultivování paměti. Jakmile je dostupná halda Javy vyčerpána, JVM se vypne. Navrženo pro interní testování JDK, ale může být myslitelně užitečné ve dvou situacích
- Velmi krátkodobé programy
- Programy jsou pečlivě napsány tak, aby znovu využívaly paměť a nikdy neprováděly nové alokace
.