Algoritmi di Garbage Collector
I Garbage Collector hanno tipicamente i seguenti obiettivi (più facile a dirsi che a farsi)
- Pause molto brevi “ferma il mondo” con un obiettivo di pochi millisecondi
- I tempi di pausa non aumentano con un heap, live-set, o root-set size
- Per gestire le dimensioni dell’heap che vanno da pochi MB fino a molti TB
- Alta concorrenza – Tutto il lavoro di sollevamento pesante è fatto mentre i thread Java continuano a eseguire
- Alta velocità di trasmissione
- Facile da sintonizzare
Garbage Collector
I dati nell’heap sono partizionati in più regioni di allocazione (o generazioni) che sono tenute separate in base all’età dell’oggetto (es.cioè il numero di iterazioni GC sopravvissute). Mentre alcuni collettori sono uni-generazionali, gli altri usano due generazioni: (1) la Young Generation (ulteriormente divisa in Eden e due regioni Survivor) e (2) la Old (o Tenured) Generation.
Fonte: Blog di Ionut Balosin
Due collettori generazionali:
Serial GC – L’algoritmo usa un singolo thread per eseguire tutto il lavoro di garbage collection, che lo rende relativamente efficiente perché non c’è overhead di comunicazione tra i thread. È più adatto a macchine a singolo processore perché non può trarre vantaggio dall’hardware multiprocessore.
Throughput (Parallel) GC – Questo algoritmo usa mark-copy nella Young Generation e mark-sweep-compact nella Old Generation. Entrambi i collettori Young e Old innescano eventi stop-the-world, fermando tutti i thread dell’applicazione per eseguire la garbage collection. Entrambi i collettori eseguono le fasi di marcatura e di copia/compattazione utilizzando più thread, da cui il nome ‘Parallelo’.
Parallel Garbage Collector è adatto a macchine multi-core nei casi in cui l’obiettivo primario è quello di aumentare il throughput. Un throughput più alto si ottiene grazie all’uso più efficiente delle risorse di sistema:
- durante la raccolta, tutti i core stanno pulendo la spazzatura in parallelo, risultando in pause più brevi
- tra i cicli di raccolta della spazzatura nessuno dei collettori sta consumando alcuna risorsa
Garbage First (G1) GC – Questo collettore è un garbage collector in stile server, mirato per macchine multiprocessore con grande memoria. Soddisfa gli obiettivi di tempo di pausa della garbage collection (GC) con un’alta probabilità, mentre raggiunge un alto throughput.
- Il collettore G1 adotta un approccio diverso in termini di modello di memoria heap. L’heap è partizionato in un insieme di regioni heap di uguali dimensioni, ciascuna un intervallo contiguo di memoria virtuale.
- A certi insiemi di regioni sono assegnati gli stessi ruoli (eden, survivor, old) come nei vecchi collettori, ma non c’è una dimensione fissa per loro.
- La dimensione delle regioni è scelta dalla JVM all’avvio. La JVM generalmente punta a circa 2000 regioni di dimensioni variabili da 1 a 32Mb. Il collettore G1 ha un approccio diverso
Per maggiori dettagli, fare riferimento a Getting Started with the G1 GC
Collettori generazionali:
Shenandoah GC – Shenandoah è il garbage collector a basso tempo di pausa che riduce i tempi di pausa del GC eseguendo più lavoro di garbage collection contemporaneamente al programma Java in esecuzione. Shenandoah esegue la maggior parte del lavoro di GC simultaneamente, compresa la compattazione simultanea, il che significa che i suoi tempi di pausa non sono più direttamente proporzionali alla dimensione dell’heap. La raccolta della spazzatura di un heap di 200 GB o di un heap di 2 GB dovrebbe avere un comportamento di pausa basso simile.
Per maggiori dettagli, fare riferimento a Dettagli di implementazione nel Wiki
Z GC – ZGC è un collettore compattante concorrente, a generazione singola, basato su regioni, NUMA-aware. Le fasi di stop-the-world sono limitate alla scansione di root, quindi i tempi di pausa del GC non aumentano con la dimensione dell’heap o del live set.
Per maggiori dettagli, fare riferimento alla Sessione su ZGC di Per Liden su YouTube
Infine,
Epsilon GC (sperimentale)- Un GC che gestisce l’allocazione della memoria ma non implementa alcun meccanismo effettivo di recupero della memoria. Una volta che l’heap Java disponibile è esaurito, la JVM si spegne. Progettato per i test interni del JDK ma può plausibilmente essere utile in due situazioni
- Programmi dalla vita molto breve
- I programmi sono attentamente scritti per riutilizzare la memoria e non eseguono mai nuove allocazioni
.