È uno dei metodi usati per eseguire la garbage collection. Si interrompe l'esecuzione del programma e si eseguono le due fasi seguenti:

Transcript

1 Parte I Garbage collection Si deniscono garbage i record allocati nello heap che non siano raggiungibili a partire dallo stack per mezzo di almeno una catena di puntatori. Il processo di recuperare tali record e renderli disponibili per l'allocazione di nuovi record, si chiama garbage collection, e non viene eseguito dal compilatore, ma a runtime, dai programmi di supporto collegati al codice compilato (in quanto, ovviamente, i record presenti in memoria dipendono dai dati che sono stati inseriti dall'utente). Per individuare il garbage, l'approccio ideale sarebbe usare la denizione dinamica della liveness. Tuttavia, non essendo questa computabile, ci dobbiamo basare sull'approssimazione conservativa della raggiungibilità del record. Il compilatore dovrà garantire che ogni variabile viva è raggiungibile e, al tempo stesso, minimizzare il numero di variabili raggiungibili che non sono vive. 1 Mark And Sweep È uno dei metodi usati per eseguire la garbage collection. Si interrompe l'esecuzione del programma e si eseguono le due fasi seguenti: Mark Si costruisce tramite un algoritmo di tipo Depth First Search il grafo dei record raggiungibili. Si considerano come radici del grafo le variabili allocate sullo stack. A partire da queste, seguendo le catene di puntatori, si individuano e segnano (mark) tutti i record raggiungibili. Sweep L'intero heap viene scandito, dal primo all'ultimo indirizzo. Tutti i record non marcati sono da considerare garbage (in quanto non raggiungibili) e vengono quindi aggiunti alla freelist (una lista a puntatori - linked list - contenente tutti i record liberi e pronti all'uso). I record marcati vengono conservati e gli viene tolta la marcatura, per prepararli alla prossima garbage collection. Al termine delle due fasi, l'esecuzione del programma viene ripresa. Un buon momento per eseguire una nuova garbage collection è quando la freelist si svuota. 1.1 Costo Il tempo di esecuzione dell'algoritmo DFS è proporzionale al numero R di nodi segnati (cioè dei record raggiungibili) ed è proporzionale alla dimensione dello heap H. L'esecuzione di una garbage collection è quindi c 1 R + c 2 H. Il costo per unità di spazio libero sullo heap, o costo ammortizzato di raccolta, è dato dal costo di esecuzione diviso per il numero H R di parole di memoria libere, cioè c1r+c2h. H R Se la memoria è quasi piena (R H) il costo è molto elevato. Se la memoria è quasi vuota (H R), il costo è molto ridotto. Se al termine del processo di collection R/H è maggiore di 0.5 (o un'altro valore, secondo qualche criterio) il collector dovrebbe chiedere al sistema operativo di fornire maggiore spazio per lo heap del programma. 1.2 Ottimizzazioni Stack esplicito Se si usa un algoritmo DFS standard (ricorsivo), si potrebbe arrivare ad avere H ricorsioni, e quindi H frame sulla pila dei record di attivazione, ossia il garbage collector occuperebbe più memoria dello HEAP stesso. Ciò è decisamente da evitare, perciò si preferisce utilizzare un algoritmo iterativo in cui si gestisce esplicitamente una struttura a pila su cui salvare i record marcati. In tal modo, si otterrà ugualmente una pila di H elementi, ma saranno singole word invece che record di attivazione Inversione dei puntatori (pointer reversal) Per ridurre ulteriormente lo spazio occupato, si può osservare che, dopo che il contenuto di un campo x.f i di un record x è stato salvato sullo stack, è possibile riutilizzare lo spazio x.f i. In particolare, è possibile utilizzarlo per salvare il puntatore al record a partire dal quale x era stato raggiunto. Secondo questo ragionamento, è quindi possibile utilizzare lo stesso grafo dei puntatori per salvare anche lo stack, facendo sì che, mentre si stanno esaminando i campi di un record (e i campi dei record a cui questi, a loro volta, puntano), ogni record 1

2 che si sta esaminando punti al proprio predecessore (cioè al record da cui è puntato) invece che al proprio successore (il record a cui punta normalmente). Ogni volta che tutti i campi di un record sono stati esaminati, i suoi puntatori vengono ripristinati, ricostruendo il grafo originale. Tutto ciò avviene secondo il seguente algoritmo: function DFS(x) if (x è un puntatore e il record a cui punta non è marcato) imposta root come predecessore (t) marca x while true if (c'è ancora un campo x.f i (contenente il valore y) da esaminare nel record x) if (y è un puntatore e il record puntato da y non è marcato) x.f i t //fai puntare il campo al suo predecessore (pointer reversal) t x //x è il predecessore del record che stiamo esaminando ora x y //il record corrente (che stiamo esaminando) è quello puntato da y marca il record corrente x else y x //salva in y l'indirizzo del record che stavamo esaminando x t //torna ad esaminare il predecessore if (x=root) tutto il grafo è stato visitato. Fine. t x.f i x.f i y //ripristino del puntatore originale (fine del pointer reversal) //il nuovo predecessore è quello il cui valore era stato salvato dall'inversione Array di freelist Per ridurre la frammentazione della memoria libera si può utilizzare, invece di un'unica freelist, un array di freelist, ognuna delle quali corrisponde ad una certa dimensione dei record ivi contenuti. In tal modo, sarà possibile utilizzare il blocco di memoria più piccolo di dimensioni sucienti a contenere la variabile da allocare. Se non ci sono blocchi sucientemente piccoli, è possibile usare il più piccolo disponibile e sprecare una parte dello spazio (se si vuole mantenere la dimensione dei blocchi), oppure suddividerlo e reimmettere nell'opportuna freelist la parte di spazio non utilizzata. La creazione delle diverse freelist è demandata alla fase sweep dell'algoritmo. L'uso di array di freelist rende anche più veloce anche l'allocazione di nuove variabili nello heap, perchè l'allocatore non dovrà cercare sequenzialmente in tutta la freelist un blocco di dimensioni sucienti, ma potrà direttamente andarlo a richiedere alle freelist di dimensioni opportune. Frammentazione esterna sono presenti tanti piccoli record liberi di dimensione insuciente per l'allocazione che si vuole eseguire. Frammentazione interna non è possibile trovare spazio libero a sucienza perchè questo è presente, inutilizzato, all'interno di record troppo grandi già allocati. 2 Conteggio dei riferimenti (Reference count) Assieme ad ogni record p, viene memorizzato un numero (reference count) che indica quanti puntatori x.f i a quel record sono presenti. Il compilatore emette istruzioni per far sì che ogni volta che un nuovo x.f i punta a p, il reference count di p viene incrementato, mentre viene decrementato quello di r a cui puntava in precedenza. Se decrementando il reference count di r questo assume il valore zero, r viene inserito nella freelist. Se esistono dei record a cui r puntava, il loro refcount deve essere a sua volta diminuito di uno. Ciò viene fatto non subito, ma al momento (successivo) in cui r verrà rimosso dalla freelist, per i seguenti motivi: 1. viene diviso in più parti il decremento ricorsivo, rendendo più uida l'esecuzione del programma 2. si risparmia spazio: il codice per il decremento ricorsivo è unico (nell'allocatore). Il codice per vericare se refcount ha raggiunto zero, tuttavia, deve comunque essere ripetuto per ogni decremento. 2

3 2.1 Problemi 1. Non si può rimuovere garbage con riferimenti ciclici: se due record non sono raggiungibili, ma puntano l'uno all'altro vicendevolmente, il loro reference count rimarrà a uno e non potranno essere rimossi. Soluzioni (a) Richiedere esplicitamente che il programmatore elimini tutti i cicli quando ha nito di usare una struttura (b) Combinare Reference Count con qualche Mark&Sweep, per rimuovere i cicli 2. La gestione dei reference count è computazionalmente pesante! Ogni operazione di aggiornamento di un puntatore implica l'incremento di un reference count, il decremento di quello della variabile puntata precedentemente e le operazioni per la verica del raggiungimento di refcount=0. È possibile attuare qualche ottimizzazione tramite analisi dataow, ma il peso è comunque elevato. 3 Collection tramite copia (Copying collection) Lo heap viene diviso in due parti, chiamate from-space e to-space. Tutti i dati sono nel from-space. Il to-space è vuoto. Attraversando il grafo dei record raggiungibili, si copiano man mano tali record nel to-space, occupando senza frammentazione i primi blocchi di memoria attigui. La copia nel to-space si dice quindi compatta. I nodi radice (le variabili dello stack) vengono quindi fatti puntare ai dati del to-space, rendendo il from-space non più raggiungibile. Alla successiva esecuzione dell'algoritmo, il from-space e il to-space saranno invertiti. Nel from space sono presenti due puntatori: next indica il punto in cui inizia la parte di memoria libera (e quindi dove, su richiesta, verranno allocate le prossime aree di memoria), limit indica il termine dello spazio disponibile. Quando next raggiunge limit, viene eseguita la collection. Durante il normale funzionamento del sistema, next può solo crescere: viene ridotto unicamente dall'esecuzione della collection. Quando si comincia l'esecuzione di una collection, next punta alla base del to-space, e viene incrementato di size(p) ogni volta che un record p viene copiato. Forwarding punta al from-space, lo si modica per puntare agli stessi dati nel to-space. Funziona in tre sottocasi diversi: È il nome dell'operazione base dell'algoritmo. Si esegue il forwarding di un puntatore p quando, dato un p che 1. Se p punta ad un record del from-space che è già stato copiato, allora p.f 1 è il forwarding pointer che indica dove si trova la copia nel to-space. È riconoscibile come tale dall'indirizzo, che è interno al to-space. 2. Se p punta al from-space, il contenuto dell'indirizzo puntato viene copiato nel to-space e p.f 1 viene fatto puntare alla nuova locazione del record. 3. Se p non è un puntatore oppure se punta al di fuori dal from-space, il forwarding non fa nulla. 3.1 Algoritmo di Cheney Esegue la copia tramite una visita breadth-rst. Non necessità di uno stack esterno o dell'inversione dei puntatori perchè introduce, a anco a next, un puntatore scan che indica quali record sono stati scanditi: i record compresi tra scan e next, sono stati copiati nel to-space ma non ancora modicati tramite forwarding (contengono riferimenti al fromspace). I record precedenti a scan, invece, sono già stati modicati dal forwarding (contengono solo riferimenti al to-space). Al termine del processo di collection, scan raggiunge next. Località dei riferimenti L'uso di un algoritmo breadth rst crea problemi con la località dei riferimenti, in quanto vengono memorizzati in aree adiacenti di memoria i record che hanno la stessa distanza dalle radici. Avrebbe invece più senso memorizzare vicini i record che sono connessi da una catena di puntatori, in quanto è molto più probabile che si dovrà accedere ad essi in sequenza e, per il funzionamento delle politiche di paginazione della memoria, facilmente in questo modo tali record verranno caricati assieme riducendo il numero di page fault e cache miss, migliorando sensibilmente le prestazioni. Una ricerca depth-rst permetterebbe di ottenere maggiore località, ma richiederebbe l'uso dell'inversione dei puntatori, risultando quindi piuttosto lenta. Un buon approccio è quello ibrido, che utilizza breadth-rst ma che, dopo aver copiato un oggetto, verica tramite depth-rst se esiste qualche suo nodo glio da copiargli vicino. 3

4 Costi Il costo della garbage collection è proporzionale al numero R di record marcati (cioè raggiungibili). Essendo lo heap (di dimensione H) suddiviso in due aree di memoria, lo spazio libero dopo una collection è H 2 R. c Il costo totale ammortizzato della collection è quindi 3 R H istruzioni per parola allocata. 2 R Per funzionare bene, in una situazione realistica si ha H = 4R. È evidente che l'occupazione di memoria è elevata. 4 Collection generazionale (generational collection) Riduce sia il tempo sia lo spazio usati dal metodo copying collection. Si basa sull'osservazione che molti oggetti sono destinati a morire presto, ma se un oggetto è sopravvissuto già ad alcune collection, è probabile che sopravviva a lungo. Dividiamo quindi lo heap in generazioni: G 0 contiene gli oggetti più giovani. Tutti gli oggetti di G 1 sono più vecchi di quelli di G 0 ; gli oggetti in G 2 sono più vecchi di quelli di G 1 e così via. Ogni area dovrebbe essere esponenzialmente più grande della precedente (es: G 0 = 0.5MB, G 1 = 2MB, G 2 = 8MB). Un oggetto che è sopravvissuto a due o tre collection viene promosso a quella successiva. Al momento di eseguire una collection (si può usare sia il metodo mark&sweep sia copying collection) la si esegue prima su G 0 e poi, se necessario, sulle generazioni via via successive. Tuttavia, per trovare gli elementi di G 0, non basta guardare le variabili nello stack: potrebbero esistere anche riferimenti all'interno di oggetti vecchi che puntano a oggetti più nuovi. Questa condizione (per fortuna rara, perchè richiede l'aggiornamento di un campo di un oggetto vecchio) renderebbe l'analisi del solo G 0 più lenta che non l'attraversamento di tutto il grafo a partire dalle radici. Per ovviare al problema facciamo si che il programma compilato ricordi dove ci sono puntatori da oggetti vecchi ad oggetti nuovi, in modo da poterli trovare immediatamente. Esistono diversi metodi per fare ciò: Remembered list viene generata una lista di oggetti di cui un campo è stato aggiornato. Al momento della garbage collection, si cercano all'interno della lista gli oggetti che puntino dentro G 0 Remembered set La remembered list potrebbe contenere duplicati di uno stesso oggetto al suo interno. Per evitare il problema, si codica all'interno dello stesso oggetto un bit per indicare l'appartenenza o meno al remembered set. Card marking La memoria è divisa in schede di dimensione 2 k. Un oggetto può occupare una o più schede, o parte di una scheda. Ogni volta che un indirizzo b viene modicato, la scheda contenente quell'indirizzo viene marcata (tramite un bit in un apposito array) Page marking Simile al precedente, ma invece di introdurre una gestione manuale delle schede, si usa la paginazione della memoria. Quando un indirizzo viene modicato, un dirty bit viene impostato per quella pagina. In ogni caso, all'inizio della garbage collection, il set di oggetti ricordati indica quali oggetti potrebbero contenere puntatori a G 0. Questi oggetti assieme alle variabili dello stack fungono da root variables per l'algoritmo di ricerca scelto. 5 Incremental collection Per ridurre il tempo di interruzione dell'esecuzione di un programma durante la garbage collection, è possibile usare algoritmi incrementali, cioè che non conducono l'intero processo di collection in un unico passaggio, ma lo eseguono un pezzo alla volta inframezzandosi alla normale esecuzione del programma. In tal caso si parla di collector per l'algoritmo di collection e di mutator per il programma in esecuzione (in quanto è in grado di modicare i dati su cui si sta lavorando). Generalmente gli algoritmi incrementali si basano su un processo di segnatura a tre colori per stabilire l'avanzamento dell'algoritmo. I record possono essere: Bianchi oggetti non ancora visitati dall'algoritmo di ricerca depth-rst o breadth-rst. Grigi gli oggetti sono già stati visitati, ma i loro gli no (è come se si trovassero sulla pila, o tra scan e next) Neri sia gli oggetti sia tutti i loro gli sono già stati visitati e marcati (è come se fossero già stati tolti dalla pila, o se fossero prima di scan). A partire dalle radici, si visitano tutti gli oggetti, rendendoli prima grigi, visitando i loro gli e inne rendendoli neri. Quando non sono più presenti oggetti grigi, tutto ciò che è rimasto bianco è garbage. Due invarianti sono comuni a tutti gli algoritmi che si basano su questo principio: 4

5 1. Gli oggetti neri non possono puntare a oggetti bianchi 2. Ogni oggetto grigio è sulla struttura dati (pila o coda) del collector. Il mutator, durante il suo lavoro, deve fare attenzione a non rompere tali invarianti, introducendo opportune politiche di coloratura: ad esempio, nell'algoritmo di Dijkstra, Lamport e altri, quanto il mutator salva un puntatore bianco a dentro ad un oggetto nero b, deve colorare a di grigio. 6 Layout dei dati Il collector deve essere in grado di operare su qualunque tipo di dato, anche complesso. Deve quindi essere in grado di determinare la dimensione occupata dai dati di ogni record, il numero di campi da cui è formato e se questi campi contengono o meno un puntatore. La prima word di un oggetto generalmente viene fatta puntare ad un record di descrizione del tipo (o della classe) che contiene l'indicazione della dimensione e la posizione dei campi puntatore. Tale record deve essere stato creato dal compilatore grazie alle informazioni ricavate dall'analisi semantica. Il compilatore deve anche permettere al collector di identicare se qualunque temporary (registro o area di memoria) contiene un puntatore. Ciò viene fatto compilando un'apposita mappa dei puntatori (pointer map) ogni volta che potrebbe essere necessario eseguire una collection, cioè ad ogni operazione alloc. 5