Memory Management Garbage Collection ceg 860 Prasad L

Memory Management Garbage Collection ceg 860 (Prasad) L 9 GC 1

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. ceg 860 (Prasad) L 9 GC 2

• 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. ceg 860 (Prasad) L 9 GC 3

• 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. • Objects 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. ceg 860 (Prasad) L 9 GC 4

ceg 860 (Prasad) L 9 GC 5

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 ceg 860 (Prasad) L 9 GC 6

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 realtime systems. ceg 860 (Prasad) L 9 GC 7

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. ceg 860 (Prasad) L 9 GC 8

(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 ceg 860 (Prasad) L 9 GC 9

Garbage Collection • Detecting and reclaiming unreachable objects automatically. • Soundness / Safety • Every collected object is unreachable. • Completeness • Every unreachable object is eventually collected. ceg 860 (Prasad) L 9 GC 10

Reachability is an Approximation • Consider the program: x ¬ new A; y ¬ new B; x ¬ y; if always. True() 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 ceg 860 (Prasad) L 9 GC 11

Soundness issue : C++ Problem void main(void){ Point *aptr = new Point(); // casting an object reference to an int i = (int) aptr; // normal access to an object and its fields aptr->print(); aptr->printxy(); // freeing an object and nulling a reference to it delete(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(); } ceg 860 (Prasad) L 9 GC 12

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. ceg 860 (Prasad) L 9 GC 13

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 }}}} ceg 860 (Prasad) L 9 GC 14

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) } ceg 860 (Prasad) L 9 GC 15

Mark and Sweep Example root A 0 B 0 C 0 D 0 E 0 free After mark: root A 1 B 0 C 1 D 0 E 0 A 0 F 1 free After sweep: root F 0 B 0 C 0 D 0 E 0 F 0 free ceg 860 (Prasad) L 9 GC 16

• 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 ceg 860 (Prasad) L 9 GC 17

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. ceg 860 (Prasad) L 9 GC 18

Stop and Copy GC: Example Before collection: root A B C D E new space heap pointer root After collection: new space ceg 860 (Prasad) F L 9 GC A C F free 19

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 ceg 860 (Prasad) L 9 GC 20

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 start copied and scanned copied objects whose pointer fields were followed ceg 860 (Prasad) scan alloc copied empty copied objects whose pointer fields were NOT followed L 9 GC 21

Stop and Copy. Example (1) • Before garbage collection root A ceg 860 (Prasad) B C D E F L 9 GC new space 22

Stop and Copy. Example (2) • Step 1: Copy the objects pointed by roots and set forwarding pointers alloc scan root A ceg 860 (Prasad) B C D E F L 9 GC A 23

Stop and Copy. Example (3) • 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 alloc – set forwarding pointer in C scan root A ceg 860 (Prasad) B C D E F L 9 GC A C 24

Stop and Copy. Example (4) • Follow the pointer in the next unscanned object (C) – copy the pointed objects (F in this case) scan root A ceg 860 (Prasad) B C D E F L 9 GC A C alloc F 25

Stop and Copy. Example (5) • Follow the pointer in the next unscanned object (F) – the pointed object (A) was already copied. Set the pointer same as the forwarding pointer alloc scan root A ceg 860 (Prasad) B C D E F L 9 GC A C F 26

Stop and Copy. Example (6) • Since scan caught up with alloc we are done • Swap the role of the spaces and resume the program root new space ceg 860 (Prasad) A L 9 GC scan C alloc F 27

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) ceg 860 (Prasad) L 9 GC 28

Generational Garbage Collection Segregate objects into multiple areas (2 ~ 7) by age, and collect older areas less often than the younger ones. ceg 860 (Prasad) L 9 GC 29

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 ceg 860 (Prasad) L 9 GC 30

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--]; } } ceg 860 (Prasad) L 9 GC 31

• 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; } ceg 860 (Prasad) L 9 GC 32

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. ceg 860 (Prasad) L 9 GC 33