ceg860 (Prasad)L9GC1 Memory Management Garbage Collection

ceg860 (Prasad)L9GC2 Modes of Object Management Static * An entity may become attached to at most one run-time object during the entire execution. E.g., FORTRAN variables. + Simple and Efficient. –Precludes recursion. –Precludes dynamic data structures. –Note, FORTRAN 90 supports recursion and pointers.

ceg860 (Prasad)L9GC3 Stack-based * An entity may at run-time become attached to several objects in succession, and the allocation and deallocation of these objects is in last-in first-out discipline. E.g., Pascal, C/C++, Java, etc. + Well-matched with block-structuring. + Allocation and Deallocation automatic. + Supports recursion. + Supports Ada “unconstrained” array types, etc. –Does not support flexible data structures.

ceg860 (Prasad)L9GC4 Heap-based * Objects are created dynamically through explicit requests. E.g., C++, LISP, Java/C#, etc. + Enables construction of complex dynamic data structures (with “unpredictable” lifetimes). –Requires techniques for memory reclamation. unreachableObjects may become unreachable as a result of an assignment or a method-return. Even systems with large virtual memory can thrash if memory is not recycled.

ceg860 (Prasad)L9GC5

ceg860 (Prasad)L9GC6 Programmer Controlled Deallocation Using language primitives E.g., Pascal’s dispose, C’s free, C++’s delete, C++ destructors, etc. –Reliability issue Dangling reference problem (“premature freeing”) Memory Leakage (“incomplete recycling”) –Ease of software development issue Component-level approach

ceg860 (Prasad)L9GC7 Automatic Memory Management Language implementation techniques (run-time system) Reference counting –Restricted to acyclic data structures. Garbage collection + Applicable to general dynamic data structures. –Unsuitable in certain areas such as hard real- time systems.

ceg860 (Prasad)L9GC8 Reference counting Keep count of number of references to each object. Update the count in response to operations. –initialize : create/clone –increment : assignment, method call –decrement : assignment, method return.

ceg860 (Prasad)L9GC9 (cont) Limitations Space/time overhead to maintain count. Memory leakage when cycles in data. Advantage Incremental algorithm Applications UNIX File System - Symbolic Links Java RMI, Strings, COM/DCOM Pure Functional Languages Scripting Languages : Python, PERL, etc

ceg860 (Prasad)L9GC10 Garbage Collection Detecting and reclaiming unreachable objects automatically. Soundness / Safety Every collected object is unreachable. Completeness Every unreachable object is eventually collected.

ceg860 (Prasad)L9GC11 Reachability is an Approximation Consider the program: x  new A; y  new B; x  y; if alwaysTrue() then x  new A else x.foo() fi After x  y (assuming y becomes dead there) the initial object A is not reachable anymore the object B is reachable (through x) thus B is not garbage and is not collected but object B is never going to be used

ceg860 (Prasad)L9GC12 Soundness issue : C++ Problem void main(void){ Point *aptr = new Point(); // casting an object reference to an int int i = (int) aptr; // normal access to an object and its fields aptr->print(); aptr->printxy(); // freeing an object and nulling a reference to itdelete(aptr); aptr = NULL; aptr->print(); // segmentation fault only when the object fields are accessed // aptr->printxy(); // casting the int back to object reference aptr = (Point*) i; // object resurrected !! aptr->print(); aptr->printxy(); }

ceg860 (Prasad)L9GC13 Mark and Sweep Mark and Sweep Algorithm Garbage Detection Depth-first search to mark live data cells (cells in heap reachable from variables on run-time stack). Garbage Reclamation Sweep through entire memory, putting unmarked nodes on freelist. Sweep also unmarks the marked nodes.

ceg860 (Prasad)L9GC14 Mark phase : Using an explicit stack function DFS(r) if r is a reference and object r not marked then { mark object r; t <- 1; stack[t] <- r; while (t > 0) { p <- stack[t--]; foreach field p.fi do { if p.fi is a reference and object p.fi not marked then { mark object p.fi; stack[++t] <- p.fi }}}}

ceg860 (Prasad)L9GC15 Sweep phase p <- first address in heap; while (p < last address in heap) { if marked object p then unmark object p else { let f be the first field in object p; p.f <- freelist; freelist <- p; } p <- p + (size of object p) }

ceg860 (Prasad)L9GC16 Mark and Sweep Example A BCDFrootE free A BCDFrootE free After mark: A BCDFrootE free After sweep:

ceg860 (Prasad)L9GC17 Problems –Memory Fragmentation. –Work proportional to size of heap. –Potential lack of locality of reference for newly allocated objects (fragmentation). Solution –Compaction –Contiguous live objects, contiguous free space

ceg860 (Prasad)L9GC18 Copying Collection Divide heap into two “semispaces”. Allocate from one space ( fromspace ) till full. Copy live data into other space ( tospace ). Switch roles of the spaces. Requires fixing pointers to moved data (forwarding). Eliminates fragmentation. DFS improves locality, while BFS does not require any extra storage.

ceg860 (Prasad)L9GC19 Stop and Copy GC: Example A BCDFrootE Before collection: new space ACF root new space After collection: free heap pointer

ceg860 (Prasad)L9GC20 Implementation of Stop and Copy We find and copy all the reachable objects into the new space, and fix ALL pointers pointing to moved objects! As we copy an object, we store in the old copy a forwarding pointer to the new copy –when we later reach an object with a forwarding pointer, we know it was already copied

ceg860 (Prasad)L9GC21 Implementation of Stop and Copy (Cont.) We still have the issue of how to implement the traversal without using extra space The following trick solves the problem: –partition the new space in three contiguous regions copied and scanned scan copied objects whose pointer fields were followed copied objects whose pointer fields were NOT followed empty copied allocstart

ceg860 (Prasad)L9GC22 Stop and Copy. Example (1) A BCDFrootEnew space Before garbage collection

ceg860 (Prasad)L9GC23 Stop and Copy. Example (2) A BCDFroot E Step 1: Copy the objects pointed by roots and set forwarding pointers A scan alloc

ceg860 (Prasad)L9GC24 Stop and Copy. Example (3) A BCDFroot E Step 2: Follow the pointer in the next unscanned object (A) –copy the pointed objects (just C in this case) –fix the pointer (to C) in A –set forwarding pointer in C A scan alloc C

ceg860 (Prasad)L9GC25 Stop and Copy. Example (4) A BCDFroot E Follow the pointer in the next unscanned object (C) –copy the pointed objects (F in this case) A scan alloc CF

ceg860 (Prasad)L9GC26 Stop and Copy. Example (5) A BCDFroot E Follow the pointer in the next unscanned object (F) –the pointed object (A) was already copied. Set the pointer same as the forwarding pointer A scan alloc CF

ceg860 (Prasad)L9GC27 Stop and Copy. Example (6) root Since scan caught up with alloc we are done Swap the role of the spaces and resume the program A scan alloc CFnew space

ceg860 (Prasad)L9GC28 Generational Collectors Observation Most objects short-lived, small percentage long lived. –80% to 98% new objects die very quickly. An object that has survived several collections has a bigger chance to become a long-lived one. –It is inefficient to copy long-lived objects over and over again. Strategy Partition objects based on age, collecting areas containing “younger” objects more frequently than “older” ones. Advantages Less effort on each collection (reduced pause time). Avoids unnecessary copying of long-lived objects (efficiency). Improves locality (temporal and spatial locality correlated)

ceg860 (Prasad)L9GC29 Generational Garbage Collection Segregate objects into multiple areas (2 ~ 7) by age, and collect older areas less often than the younger ones.

ceg860 (Prasad)L9GC30 Practical Issues –Unpredictability Major concern in critical applications. + Support collect_on, collect_off, collect_now. –Efficiency Generation scavenging; Clustering –Incrementality Separate GC thread running concurrently. –Finalization Recycling non-memory resources. –External Calls Interfacing with other languages

ceg860 (Prasad)L9GC31 Memory Leakage in Java (Unintended References) public class Stack { private static final int MAXLEN = 10; private Object stk[] = new Object[MAXLEN]; private int stkp = -1; public void push(Object p) { stk[++stkp] = p; } public Object pop() { return stk[stkp--]; }

ceg860 (Prasad)L9GC32 In order to ensure that the popped object is promptly available to the garbage collector, it must be made explicitly “unreachable” by setting the object reference in stk[top] to null. public Object pop(){ Object p = stk[stkp]; stk[stkp--] = null; return p; }

ceg860 (Prasad)L9GC33 Other Java Details Class representations stay in memory as long as the corresponding class loader is present. This is because the contents of the class (static) variables may be needed later. Unintended references from class variables to instances can cause memory leakage. See Reference Objects and java.lang.ref package in Java 2 for GC related issues.