G1 Garbage Collector

Questo post è sostanzialmente una traduzione di quanto trovato in rete in altra lingua. Trovo sia molto più comodo avere un raccoglitore rapido in lingua italiana per chi volesse cimentarsi nell’utilizzo di questo nuovo Garbage Collector senza perdersi nelle varie pagine. Tutte le fonti di mera traduzione, sono citati nelle Web References e sono pubblicamente accessibili.

Descrizione

Cosa è G1? G1 (che sta per “Garbage First”) è un nuovo Garbage Collector introdotto da Oracle a partire dal jdk 1.7.0u9. Da quanto si legge nei documenti ufficiali, sembra essere un collector specificatamente pensato per applicazioni server su istanze con ram corposa e necessità di tempi di collezione prevedibili e stabili.

Nozioni di base sui processo di Garbage Collection

Il Garbage Collection Process si occupa della gestione della memoria della jvm, liberando lo spazio occupato dagli oggetti non piu’ vivi.
La memoria degli oggetti (Heap) è divisa in zone logiche dove risiedono oggetti omogenei per età. Alla nascita (allocazione) un oggetto viene posizionato nella “Young Generation”, se sopravvive abbastanza viene promosso alla “Old Generation”.
La young generation è composta da uno spazio iniziale, chiamato “Eden”, più due zone chiamate “Survivor Space S0″ e “Survivor Space S1″. Gli oggetti che sono ancora attivi dopo l’eden, passano allo spazio S0 e poi S1. Quando la Young Generation si riempie, avviene una “Minor Collection”; quando si riempie la Old, avviene una “Major Collection”.

Funzionamento

Lo heap viene diviso in regioni contigue di uguale dimensione. Concorrentemente all’applicazione, G1 controlla le zone di memoria singolarmente e marca quelle con maggior numero di bytes recuperabili. Successivamente (ed entro i tempi “goal” definibili dall’utente), viene fatta la collezione tramite “vacuum”, ossia viene svuotata una zona e spostati i bytes superstiti in un altra. Questo permette di liberare memoria e di deframmentare lo heap nello stesso tempo. Come paragone, possiamo considerare il CMS (Concurrent Mark Sweep) e il ParallelOld. Il primo non effettua deframmentazione, mentre il secondo effettua solo una deframmentazione totale (che comporta dei tempi di stop elevati). G1 utilizza i tempi di collezione precedenti per stimare quante zone potrà collezionare rimanendo nei tempi di stop richiesti.

Scopo

G1 è stato pensato come un rimpiazzo per CMS. Dai documenti sembra che sia un ottimo sostituto del CMS, particolarmente adatto a sistemi che hanno facoltosi heap (6Gb) e richiedono delle pause basse, anche sotto i 500ms. L’optimum si raggiunge con una occupazione dello heap dove oltre il 50% sono oggetti non collezionabili (ma vivi) e dove il numero di oggetti vivi cambia frequentemente (e beneficia quindi di un deframmentatore).

Approfondimenti sul funzionamento

Lo heap viene diviso in zone di egual dimensione, che vanno da 1Mb a 32Mb. Vengono create al massimo 2048 regioni (quindi, per quanto distante sia questo limite, non possono essere allocati più di 64Gb di heap). La dimensione della Young Generation viene variata dinamicamente in base all’esperienza maturata nelle collezioni precedenti, allo scopo di mantenere la durata delle collezioni entro i limiti impostati.

Web References:
[1] G1 Introduction
[2] G1 Tuning
[3] G1 Draft su ACM

Primo giretto a milano in bici!

Grazie a Daniele, che mi ha portato la bici fino a casa, oggi ho potuto fare il primo giro/test.

Ovviamente, ho sperimentato il percorso per arrivare a lavoro. Altrettanto ovviamente, ho sbagliato strada un paio di volte e sono stato costretto a vedermela con mille piccoli dettagli sulle strade enormi di milano.

Alla fine, tutto compreso, ho impiegato 14 minuti circa…niente male, rispetto agli oltre 40 necessari con i mezzi pubblici :)

Percorso da casa a lavoro, in bici