RUN TIME ENVIRONMENT

Transcript

1 RUN TIME ENVIRONMENT MEMORY ORGANIZATION Compiler must do the storage allocation and provide access to variables and data Memory management Stack allocation Heap management Garbage collection 1

2 MEMORY ORGANIZATION hypothesis Run time memory is based on contigued bytes The smaller addressed space is a byte (4 bytes = word) The number of bytes for a date depend on its type The memory structure depend on the target machine The space (in bytes) required for the code is calculated at compile time. Code Static Steak Free memory Heap 3 STATIC VS. DYNAMIC ALLOCATION Static: Compile time, Dynamic: Runtime allocation Many compilers use some combination of following Stack storage: for local variables, parameters and so on Heap storage: Data that may outlive the call to the procedure that created it Stack allocation is a valid allocation for procedures since procedure calls are nested 2

3 STATIC VS. DYNAMIC ALLOCATION Static Compile time Code based Dynamic Run time Code + Data based Strategies Stack allocation Heap allocation 5 STORIA DELL ALLOCAZIONE DELLA MEMORIA Allocazione statica (Static allocation) Una caratteristica del Fortran (fino al Fortran77) Implca che le dimenzioni degli arrays sia conosciuta a compile time no funzioni o sottoprogrammi ricorsivi Nessuna allocazione dinamica di strutture dati Grande Efficienza: l accesso ai dati è di norma diretto Sicurezza Nessuna possibilita di out of memory a runtime 3

4 STORIA DELL ALLOCAZIONE DELLA MEMORIA Stack Allocation Introdotta con Algol58 Il tempo di vita (lifetime) è collegato con l attivazione delle procedure Implementato attraverso l utilizzo dei record di attivazione (stack frame): Differenti invocazioni istanziano differenti versioni delle variabili locali; il valore delle variabili locali non persiste fra successive invocazioni del sottoprogramma La dimenzione delle strutture dati locali può dipendere da un parametro È supportata le ricorsione La dimenzione del valore ritornato da una funzione deve essere nota a compile time Gli oggetti possono essere allocati dinamicamente nello stack ma sono comunque deallocati quando termina la procedure STACK ALLOCATION 4

5 SKETCH OF A QUICKSORT PROGRAM ALLOCAZIONE DELLA MEMORIA STACK Alla chiamata di un sottoprogramma una certa quantità di memoria (per variabili locali etc) viene impilata nello stack Quando il sottoprogramma termina tale memoria viene rimossa dallo stack Cio permette di compilare i sottoprogrammi in modo che l indirizzo relativo delle sue variabili locali sia sempre lo stesso indipendentemente dalla chiamata 10 5

6 ACTIVATION FOR QUICKSORT ALBERO DI ATTIVAZIONE Dato che le chiamate di procedura sono annidate nel tempo possiamo utilizzare una rappresentazione di tale chiamate utilizzando un albero detto albero di attivazione Le attivazioni sono riportate sull albero seguendo da sx a dx l ordine in cui sono state chiamate Un figlio deve terminare prima che possa iniziare l attiviazione alla sua destra La sequenza delle chiamate corrisponde ad una visita in preordine dell albero di attivazione La sequenza dei ritorni corrisponde ad una visita in postordine dell albero delle attivazioni 12 6

7 ACTIVATION TREE REPRESENTING CALLS DURING AN EXECUTION OF QUICKSORT ACTIVATION RECORDS Procedure calls and returns are usaully managed by a run-time stack called the control stack. Each live activation has an activation record (sometimes called a frame) The root of activation tree is at the bottom of the stack The current execution path specifies the content of the stack with the last activation has record in the top of the stack. 7

8 A GENERAL ACTIVATION RECORD Temporary values Local data A saved machine status An access link A control link Space for the return value of the called function The actual parameters used by the calling procedure DOWNWARD-GROWING STACK OF ACTIVATION RECORDS 8

9 DESIGNING CALLING SEQUENCES Values communicated between caller and callee are generally placed at the beginning of callee s activation record Fixed-length items: are generally placed at the middle Items whose size may not be known early enough: are placed at the end of activation record We must locate the top-of-stack pointer judiciously: a common approach is to have it point to the end of fixed length fields. DESIGNING CALLING SEQUENCES The caller evaluates the actual parameters The caller stores a return address and the old value of top-sp into the callee's activation record. The callee saves the register values and other status information. The callee initializes its local data and begins execution. Parameter and return value Control link Stauts Temporaries an local data Parameter and return value Control link Stato salvato Dati temporanei e locali chiamante chiamato 18 9

10 DIMENSION VARIABLE Two pointers are required top_sp e top top_sp top Parametri attuali e valore di ritorrno Control link Stato salvato Puntatore ad a Puntatore ad b Array a Array b Parametri attuali e valore di ritorrno Control link Stato salvato Dati temporanei e locali 19 CORRESPONDING RETURN SEQUENCE The callee places the return value next to the parameters Using information in the machine-status field, the callee restores top-sp and other registers, and then branches to the return address that the caller placed in the status field. Although top-sp has been decremented, the caller knows where the return value is, relative to the current value of top-sp; the caller therefore may use that value. 10

11 ACCESS TO DYNAMICALLY ALLOCATED ARRAYS SEQUENZA DI RITORNO Il chiamato Posiziona il valore di ritorno subito dopo i parametri Ripristina il registro top.sp e gli altri registri quindi passa il controllo all indirizzo di controllo salvato fra informazioni di stato. Recupera il valore dello stack pointer 22 11

12 ACCESSO ALLE VARIABILI NON LOCALI IN ASSENZA DI PROCEDURE ANNIDATE Lo scope in tal caso è costituito dalle variabili locali e dalle variabili globlali Le variabili globali vengono allocate nella parte di memoria riservata ai dati statici Le variabili locali nel record di attivazione del sottoprogramma dove sono definite 23 ACCESSO ALLE VARIABILI NON LOCALI IN PRESENZA DI PROCEDURE ANNIDATE: USO DELL ACCESS LINK La procedura q con livello di annidamento n q richiama la procedura p con livello di annidamento n p n p > n q, in tal caso p deve essere definita all interno di q in tal caso è semplice ad access link di p viene copiato il valore del record di attivazione di q La chiamata è ricorsiva (p=q), in questo caso l access link della nuova attivazione è identico alla precedente n p < n q la procedura q deve essere annidata in r e la definizione di p deve essere immediatamente annidata in r. Il recordi di attivazione più recente di r puo essere localizzato seguento la catena si access link per n p n q + 1 passi

13 ACCESSO ALLO SCOPE TRAMITE DISPLAY È un array di puntatori di dimensione pari al livello di annidamento Ciascun puntatore punta al record di attivazione più in alto nello stack con quel livello di annidamento 25 ALLOCAZIONE DELLA MEMORIA Heap Allocation Lisp (~1960) Gli oggetti sono allocati e deallocati dinamicamente, in qualsiasi ordine, e il lifetimes degli oggetti non sono correlati con la invocazione delle funzioni Permette strutture dati ricorsive (eg alberi) La dimenzione delle strutture dati può variare dinamicamente Oggetti dimenzionati dinamicamente possono esser ritornati come risultato di una funzione Permette ai linguaggi di programmazione di supportare first-class functions (che sono implementate per mezzo di closures) Molti moderni linguaggo forniscono sia stack che heap allocation 26 13

14 MEMORY MANAGER Two basic functions: Allocation Deallocation Properties of memory managers: Space efficiency Program efficiency Low overhead TYPICAL MEMORY HIERARCHY CONFIGURATIONS 14

15 LOCALITY IN PROGRAMS The conventional wisdom is that programs spend 90% of their time executing 10% of the code: Programs often contain many instructions that are never executed. Only a small fraction of the code that could be invoked is actually executed in a typical run of the program. The typical program spends most of its time executing innermost loops and tight recursive cycles in a program. ALLOCAZIONE ESPLICITA SU HEAP Esempi sono C, C++, Pascal dove il programma alloca e dealloca memoria heap per gli oggetti Garbage = dispersione della mamoria Se non ci sono altri puntatori che puntano al primo alemento della lista quando termina la funzione gli oggetti diventano irragiungibili quindi garbage 30 15

16 Allocazione esplicita su Heap Dangling references free( P->next ); 31 Allocazione esplicita su Heap Dangling references which has caused P->next to become a dangling pointer (and a potential delayed effect run-time error) as well as creating some garbage 32 16

17 PERCHÈ GARBAGE COLLECT? Quando eseguiamo list = list->next; // cancella il primo elementoelement Il programma dovrebbe deallocare gli oggetti condivisi? (questo è complesso ma corretto) 33 ALLOCAZIONE/DEALLOCAZIONE ESPLICITA. PROBLEMI? Quale funzione è responsabile della deallocazione di un oggetto quando non è più necessario? Gli oggetti condivisi fra diverse strutture dati rendono complesso conoscere quando viene rimossa l ultimo riferimento Una soluzione comune è aggiungere un reference counts agli oggetti (ma questa soluzione ha alcuni problemi) Un alternativa e duplicare (Cloning) gli oggetti in modo da eliminare il problema della condivisione degli oggetti. Questa soluzione non è efficiente. Memory allocation errors are a major source of problems in C/C++ code (random crashes, memory leaks) Esistono numerosi tool per la localizzazione di errori di memory allocation (Purify, ObjectCenter, Insure++) 34 17

18 GARBAGE COLLECTION 35 THE ESSENCE Programming is easier if the run-time system garbage-collects --- makes space belonging to unusable data available for reuse. Java does it; C does not. But stack allocation in C gets some of the advantage

19 DESIDERATA 1. Speed --- low overhead for garbage collector. 2. Little program interruption. Many collectors shut down the program to hunt for garbage. 3. Locality --- data that is used together is placed together on pages, cache-lines. 37 THE MODEL --- (1) There is a root set of data that is a-priori reachable. Example: In Java, root set = static class variables plus variables on run-time stack. Reachable data : root set plus anything referenced by something reachable

20 THE MODEL --- (2) Things requiring space are objects. Available space is in a heap --- large area managed by the run-time system. Allocator finds space for new objects. Space for an object is a chunk. Garbage collector finds unusable objects, returns their space to the heap, and maybe moves objects around in the heap. 39 GARBAGE COLLECTION Garbage collection (GC) - Il processo di recuperare tali record e renderli disponibili per l'allocazione di nuovi record, 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 definizione 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

21 ESEMPIO DI GARBAGE class node { int value; node next; } node p, q; p = new node(); q = new node(); q = p; delete p; 41 IL GARBAGE COLLECTOR PERFETTO Nessun impatto visibile sull esecuzione del programma Opera con qualsiasi programma e sulle sue strutture dati: Ad esempio gestisce le strutture dati ciclliche Recupera tutte le celle garbage (e solo quelle garbage) rapidamente Incrementale, può soddisfare requisiti real-time Ha un eccellente gestione della localita spaziale dei riferimenti No eccessivo paging, nessun effetto negativo sulla cache Gestisce l heap efficentemente Soddisfa sempre le richieste di allocazione e non provoca frammentazione della memoria heap

22 COSTO DEL GC I primi sistemi Lisp furono noti per i lunghi stop nel mezzo di sessioni interattive a causa dell esecuzione del gc. Algoritmi migliori e processori più veloci hanno reso il gc un problema molto minore. GC è ancora da evitare per molte applicazioni real-time (dove il tempo di risposta richiesto e inferiore ai millisecondi), Per la maggior parte delle applicazioni. Il problema è: Which is more important:software which is free of memory leaks and memory allocation errors,... or software which is a little faster but less reliable and takes twice as long1 to debug? 43 A HEAP Free List Object 1 Object 2 Object 3 22

23 TAXONOMY Garbage Collectors 45 Reference- Counters Trace- Based REFERENCE COUNTING The simplest (but imperfect) method is to give each object a reference count = number of references to this object. OK if objects have no internal references. Initially, object has one reference. If reference count becomes 0, object is garbage and its space becomes available

24 REFERENCE COUNTING Una tecnica semplice utilizzata in molti sistemi, eg, Unix usa tenere traccia di quando un file può essere cancellato C++ smart pointer (e.g., auto_ptr) usa il e reference counter Il costo del gc è distribuito sull intero programma esecuzione Richiede spazio e tempo per memoriazzare e incrementare (decrementare) il conatore ogni qualvolta un riferimento ad una cella e aggiunto (eliminato) 47 EXAMPLES Integer i = new Integer(10); Integer object is created with RC = 1. j = k; (j, k are Integer references.) Object referenced by j has RC--. Object referenced by k has RC

25 TRANSITIVE EFFECTS If an object reaches RC=0 and is collected, the references within that object disappear. Follow these references and decrement RC in the objects reached. That may result in more objects with RC=0, leading to recursive collection. 49 REFERENCE COUNTING Assieme ad ogni record p, viene memorizzato un numero (reference count) che indica quanti puntatori x.fi a quel record sono presenti. Il compilatore emette istruzioni per far sì che ogni volta che un nuovo x.fi 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

26 PSEUDO-CODICE PER REFERENCE COUNTING // chiamatta dal programma per creare // una nuova istanza di un oggetto function New(): if freelist == null then report an error; newcell = allocate(); newcell.rc = 1; return newcell; // chiamata dal programma per // overwrite una variabile // puntatore R with con un // altro valore S procedure Update(var R, S): if S!= null then S.rc += 1; delete(*r); *R = S; // chiamata da New function allocate(): newcell = freelist; freelist = freelist.next; return newcell; // chiamata da Update procedure delete(t): T.rc -= 1; if T.rc == 0 then foreach pointer U held inside object T do delete(*u); free(t); // chiamata da delete procedure free(n): N.next = freelist; freelist = N; 51 rc è il campo reference count dell oggetto REFERENCE COUNTING: EXAMPLE Heap space root set

27 BENEFICI DEL REFERENCE COUNTING overhead incrementale GC overhead è distribuito lungo tutta la computazione ==> tempo di risposta omogeneo nelle situazioni interattive. (Contrasto con stop and collect approach.) Applicazioni real-time Riuso immediato delle celle libere se RC == 0, la cella è aggiunta alla put free list 53 BENEFICI DEL REFERENCE COUNTING Semplicità dell implementazione Può coesistere con la gestione manuale della memoria heap Buona gestione della località spaziale il programma accede alle locazioni di memoria che probabilmente sono sul punto di di essere utilizzare. (In contrasto con una marking phase durante la quale viene scorsa tutta la memoria) la maggioranza degli oggetti hanno una vita breve; il reference counting recupererà e riutilizzera tali oggetti rapidamente. (In contrasto con con uno schema dove gli oggetti morti rimangono inutilizzati per un lungo periodo vino a quando il prossimo gc a rilevato un out of memory.) 54 27

28 REFERENCE COUNTING: PROBLEMI Space overhead 1 word per il contatore Time overhead Ogni volta che un puntatore è aggiornato: aggiornare due reference counters (decrementare il vecchio target, incrementare il sorgente). L accesso in memoria è costoso. Il codice è fragile (se prodotto by hand) È molto facile dimenticare di incrementare o decrementare un reference counter (eg quando si passa un oggetto ad un sottoprogramma) Dimenticare un incremento ==> strange bugs, Dimenticare un decremento ==> memory leaks. 55 REFERENCE COUNTING: CYCLES root set Heap space 1 Memory leak

29 PROBLEMI Non si può rimuovere memoria 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 Richiedere esplicitamente che il programmatore elimini tutti i cicli quando ha finito di usare una struttura Combinare Reference Count con qualche Mark&Sweep, per rimuovere i cicli 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 dataflow, ma il peso è comunque elevato. 57 REFERENCE COUNTING Strutture dati cicliche La soluzione ovvia e combinare reference counting con gli altri schemi di gc Eseguire gli altri schemi di gc quando La memoria e esaurita Ad intervalli regolari Questo permette di utilizzare meno memoria per i reference counts Per esempio si possono utilizzare campi di 8 bit per il counter. Quando il counter supera il valore massimo, 255, rimane bloccato Quando viene eseguito il gc, recupera gli oggetti cil cui contatore dovrebbe essere zero e resetta i contatori degli altri oggetti

30 TAXONOMY Garbage Collectors 59 Reference- Counters Trace- Based Stop-the-World Short-Pause Mark-and- Sweep Mark-and- Compact Basic MODELLO ASTRATTO Gli algoritmi basati sulla traccia calcolano l insieme degli oggetti raggiungibili e poi prendono il complemento di tali oggetti Processo di riciclo della memoria Il programma mutatore viene eseguito ed effettua richesta di allocazione Il GC determina la raggiungibilità degli oggetti mediante algoritmi basati su traccia Il GC rilascia la memoria degli oggetti non raggiungibili 60 30

31 FOUR STATES OF MEMORY CHUNKS 1. Free = not holding an object; available for allocation. 2. Unreached = Holds an object, but has not yet been reached from the root set. 3. Unscanned = Reached from the root set, but its references not yet followed. 4. Scanned = Reached and references followed. 61 MARKING 1. Assume all objects in Unreached state. 2. Start with the root set. Put them in state Unscanned. 3. while Unscanned objects remain do examine one of these objects; make its state be Scanned; add all referenced objects to Unscanned if they have not been there; end; 62 31

32 SWEEPING Place all objects still in the Unreached state into the Free state. Place all objects in Scanned state into the Unreached state. To prepare for the next mark-and-sweep. 63 MARK-SWEEP GARBAGE COLLECTION Ogni cella ha un bit di mark Le locazioni di memoria garbage rimane non raggiungibile e inutilizzata fino a quando l heap non è piena: quando agisce il GC il programma in esecuzione viene sospeso Fase di Marking Partendo dai roots, aggiorna il mark bit di tutte le celle live Fase di Sweep Inserisce tutte le celle non marcate nella free list Reset il mark bit di tutte le celle marcate 64 32

33 MARK-SWEEP (AKA MARK-SCAN) ALGORITHM Il primo utilizzo sembra essere in Lisp La memorizzazione per i nuovi oggetti è ottenuto da un free-pool Nessuna azione extra è eseguita quando il programma copia o sovrascrive i puntatori Quando il pool di libero è esaurito, il New () invoca il mark-sweep gc per reinserire la memoria occupata da oggetti inaccessibili al free-pool e quindi ricomincia MARK-SWEEP EXAMPLE (1) Heap space 66 root set 33

34 MARK-SWEEP EXAMPLE (2) Heap space 67 root set MARK-SWEEP EXAMPLE (3) Heap space 68 root set 34

35 MARK-SWEEP EXAMPLE (4) root set Heap space Free unmarked cells 69 Viene resettato Il mark bit Delle celle marcate ALGORITMO DI MARK_SWEEP Fase di marcatura Poni il reached bit a 1 e aggiungi alla lista Unscanned ogni oggetto avente un riferimento nel root-set while (Unscanned!= 0){ rimuovi un oggetto o da Unscanned for (ogni oggetto o avente un riferimento in o){ } if (il reached-bit di o ==0) { } poni il reached-bit di o ad 1; aggiungi o alla lista Unscanned } 70 35

36 ALGORITMO DI MARK_SWEEP Fase di pulizia Free = 0; For (ogni blocco di memoria o nell heap){ if (il reached-bit di o ==0) aggiungi o alla lista Free else poni il reached-bit di o ad 0; } La lista Free contiene oggetti disponibili La lista Unscanned contiene oggetti che sappiamo essere raggiungibili che non sono stati analizzati per verificare se fanno riferimento ad altri oggetti 71 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 c1r + c2h. 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

37 TAXONOMY Garbage Collectors 73 Reference- Counters Trace- Based Stop-the-World Short-Pause Mark-and- Sweep Mark-and- Compact Basic Baker s BAKER S ALGORITHM --- (1) Problem: The basic algorithm takes time proportional to the heap size. Because you must visit all objects to see if they are Unreached. Baker s algorithm keeps a list of all allocated chucks of memory, as well as the Free list

38 BAKER S ALGORITHM --- (2) Key change: In the sweep, look only at the list of allocated chunks. Those that are not marked as Scanned are garbage and are moved to the Free list. Those in the Scanned state are put in the Unreached state. For the next collection. 75 STATI Free: zona di memoria disponibile per essere allocata Unreached: blocchi non raggiungibili, tutti i blocchi inizialmente sono considerati non raggiungibili e vengono riposti nello stato unreached dopo il completamento del gc I blocchi raggiungibili possono essere Scanned UnScanned 76 38

39 ALGORITMO DI BAKER Fase di marcatura Scanned = 0 UnScanned = insieme degli oggetti raggiungibile dall insieme radice while (Unscanned!= 0){ } sposta un oggetto o da Unscanned a Scanned for (ogni oggetto o avente un riferimento in o){ if (o appartiend a lista UnReached) sposta o da UnReached a Unscanned 77 ALGORITMO DI MARK_SWEEP Fase di pulizia Free = Free UnReached; UnReached = UnScanned 78 39

40 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. 79 OTTIMIZZAZIONI: INVERSIONE DEI PUNTATORI (POINTER REVERSAL) Per ridurre ulteriormente lo spazio occupato, si può osservare che, dopo che il contenuto di un campo x.fi di un record x è stato salvato sullo stack, è possibile riutilizzare lo spazio x.fi. 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 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

41 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.fi (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 x y //il record corrente è 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.fi //il nuovo predecessore è quello il cui valore era stato salvato dall'inversione x.fi y //ripristino del puntatore originale (fine del pointer reversal) 81 OTTIMIZZAZIONE: 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 sufficienti a contenere la variabile da allocare. Se non ci sono blocchi suffientemente 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. 1. Frammentazione esterna: sono presenti tanti piccoli record liberi di dimensione insufficiente 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

42 MARK-SWEEP COSTS AND BENEFITS Vantaggi Gestisce le strutture cicliche Nessun space overhead 1 bit utilizzato per marcarre le celle Svantaggi L esecuzione del programma viene sospesa Può influenza la gestione della memoria virtuale Può causare un paging eccessivo se la dimenzione del working-set size è piccola e l heap non è tutta nella memoria fisica L heap può essere frammentata 83 TAXONOMY Garbage Collectors 84 Reference- Counters Trace- Based Stop-the-World Short-Pause Mark-and- Sweep Mark-and- Compact Basic Baker s Basic 42

43 ISSUE: WHY COMPACT? Compact = move reachable objects to contiguous memory. Locality --- fewer pages or cache-lines needed to hold the active data. Fragmentation --- available space must be managed so there is space to store large objects. 85 MARK-AND-COMPACT 1. Mark reachable objects as before. 2. Maintain a table (hash?) from reached chunks to new locations for the objects in those chunks. Scan chunks from low end of heap. Maintain pointer free that counts how much space is used by reached objects so far

44 MARK-AND-COMPACT --- (2) 3. Move all reached objects to their new locations, and also retarget all references in those objects to the new locations. Use the table of new locations. 4. Retarget root references. 87 EXAMPLE: MARK-AND-COMPACT 88 free 44

45 EXAMPLE: MARK-AND-COMPACT 89 free EXAMPLE: MARK-AND-COMPACT 90 free 45

46 EXAMPLE: MARK-AND-COMPACT 91 free EXAMPLE: MARK-AND-COMPACT 92 free 46

47 EXAMPLE: MARK-AND-COMPACT 93 free EXAMPLE: MARK-AND-COMPACT 94 free 47

48 EXAMPLE: MARK-AND-COMPACT 95 free EXAMPLE: MARK-AND-COMPACT 96 free 48

49 MARK AND COMPACT Una volta effettuata la marcatura invece di procedere alla rimozione è conveniente ricopiare tutti gli oggetti raggiungibili verso uno dei due estremi dell heap 97 ALGORITMO DI MARK_COMPACT Fase di marcatura UnScanned insieme degli oggetti raggiungibili dall insieme radice while (Unscanned!= 0){ rimuovi un oggetto o da Unscanned for (ogni oggetto o avente un riferimento in o){ } if (o non è stato ragiunto) { } marca o come ragiunto aggiungi o alla lista Unscanned } 98 49

50 ALGORITMO DI MARK_COMPACT Calcolo delle nuove locazioni For (ogni blocco di memoria o nell heap a partire dal basso){ if (o è ragiunto) { for (ofni riferimento o.r in o new Location(0) = free; free = free + sizeof(o) } 99 ALGORITMO DI MARK_COMPACT Fase di aggiornamento dei riferimenti For (ogni blocco di memoria o nell heap a partire dal basso){ } if (o è ragiuunto) { for (ogni ogni riferimento 0.r in o) } o.r = new Location(o,r) = free; for (ogni riferimento r nell insieme radice) r = new Location (r);