1 Key Issues Reference Counting Idea For both for each heap - PowerPoint PPT Presentation

Garbage Collection Background Last time Static allocation: variables are bound to storage at compile-time – Compiling Object-Oriented Languages – pros: easy to implement – cons: no recursion, data structure sizes are compile-time constants, data structures cannot be dynamic Today – Motivation behind garbage collection Stack allocation: dyn. alloc. stack frame for each proc. invocation – Garbage collection basics – pros: recursion is possible, data structure sizes may depend on parameters – Garbage collection performance – cons: stack allocated data is not persistent, stack allocated data cannot – Specific example of using GC in C++ outlive the procedure for which it is defined Acknowledgements Heap allocation: arbitrary alloc. and dealloc. of objects in *heap* – These slides are based on Kathryn McKinley’s slides on garbage – pros: solves above problems: dynamic, persistent data structures collection as well as E Christopher Lewis’s slides – cons: very difficult to explicitly manage heap CS553 Lecture Garbage Collection 1 CS553 Lecture Garbage Collection 2 Memory Management Explicit versus Automatic Explicit Ideal (not possible) + efficiency can be very high – deallocate all data that will not be used in the future + gives programmers “control” – more code to maintain What is garbage? – correctness is difficult – core dump if an object is freed too soon – space is wasted if an object is freed too late – if never free, at best waste space, at worst fail Automatic Manual/Explicit + reduces programmer burden – programmer deallocates with free or delete + eliminates sources of errors + integral to modern OOP languages (ie. Java, C#) – can not determine all objects that won’t be used in the future Automatic/Implicit – may or may not hurt performance – garbage collection CS553 Lecture Garbage Collection 3 CS553 Lecture Garbage Collection 4 1

Key Issues Reference Counting Idea For both – for each heap allocated object, maintain count of # of pointers to it – Fast allocation – when creating object x, rc[x] = 0 – Fast reclamation – when creating new reference to object x, rc[x]++ – Low fragmentation (wasted space) – when removing reference to object x, rc[x]-- – if ref count goes to zero, free object (i.e., place on free list) For Garbage Collection Example null – How to discriminate between live objects and garbage Node x, y; x x = new Node (3, null); Basic approaches to garbage collection y = x; Node y x = null; – reference counting y = x; – reachability rc = 1 2 1 0 Complication – what if freed object contains pointers? CS553 Lecture Garbage Collection 5 CS553 Lecture Garbage Collection 6 Reference Counting Analysis Trace Collecting Observation How it handles key issues – rather than explicitly keep track of the number of references to each object – allocation is expensive because searching a freelist we can traverse all reachable objects and discard unreachable objects – reclamation is local and incremental – fragmentation is high Details – start with a set of root pointers (program vars) – global pointers Further analysis – pointers in stack and registers + relatively simple – traverse objects recursively from root set + very simple run-time system – visit reachable objects – cannot reclaim cyclic data structures (shifts burden to programmer) – unvisited objects are garbage – high runtime overhead (must manipulate ref counts for every reference – we might visit an object even if it's dynamically dead (ie, we are only update) conservatively approximating dead object discovery) – space cost – complicates compilation When do we collect? – when the heap is full CS553 Lecture Garbage Collection 7 CS553 Lecture Garbage Collection 8 2

Mark-Sweep Collecting Mark-Sweep Collecting Analysis Simple trace collector How it handles the key issues – trace reachable objects marking reachable objects – allocation is expensive because searching a freelist – sweep through all of heap – reclamation can result in the “embarrassing pause” problem – add unmarked objects to free list – poor memory locality when tracing – clear marks of marked objects – fragmentation is high Example Further analysis + collects cyclic structures T x T T + simple – must be able to dynamically identify pointers in vars and objects y F – more complex runtime system T – space overhead is only one bit per data object F CS553 Lecture Garbage Collection 9 CS553 Lecture Garbage Collection 10 Mark-Compact Collecting or Copy Collecting Copying Garbage Collection Idea – move objects to “new” heap while tracing Details – divide heap in half (prog. allocs. in from-space, to-space is empty) – when from-space is full... – copy non-garbage from from-space to to-space (to-space is compact) when visiting object during tracing ‘from space’ ‘from space’ ‘to space’ ‘to space’ ‘to space’ ‘to space’ ‘to space’ ‘from space’ ‘from space’ ‘from space’ ‘to space’ ‘to space’ – copy from from-space to to-space – leave forwarding pointer in from-space version of object – if revisit this object, redirect pointer to to-space copy CS553 Lecture Garbage Collection 11 CS553 Lecture Garbage Collection 12 3

Mark-Compact Collecting Analysis Hybrid Collectors How it handles the key issues Idea – allocation is very fast since there is no free list to search – different collection techniques may be combined – reclamation can result in the “embarrassing pause” problem – poor memory locality when tracing Example: Mark-Sweep/Copy collector – copying data from one heap to another – big objects managed with mark-sweep (avoids copy time) – changing pointers because objects are being moved – small objects managed with copy collector + visits only reachable objects – no fragmentation Analysis + may be more efficient Further Analysis – more complex + collects cyclic structures – requires twice the (virtual) memory – breadth-first traversal means to-space objects could have poor locality CS553 Lecture Garbage Collection 13 CS553 Lecture Garbage Collection 14 Generational Collecting Generational Collecting (cont) Observation Additional issues – "young" objects are most likely to die soon, while "old“ objects are more – need to encode “age” in object likely to live on – root set for objects in one generation may come from another gen. – generation Gi should be k times larger than Gi-1 Idea – each generation may be collected with different algorithm – exploit this fact by concentrating collection on "young" objects Dealing with cross-generation pointers Details – older to younger ( i.e., Gi to Gj for i>j) are uncommon – divide heap in generations (G0, G1, ...; G0 for youngest objects) – collect G0 most frequently, G1 less frequently, etc . – search all of Gi? – object is “tenured” from one gen. to next after surviving several GCs – write barriers – younger to older ( i.e., Gj to Gi for i>j) are very common Result – collect Gj when collecting Gi – usually only have to collect a small sub-heap CS553 Lecture Garbage Collection 15 CS553 Lecture Garbage Collection 16 4

Generational Collecting Analysis Who does what? Pointers How it handles the key issues Issues – allocation in the youngest heap is fast if a copy collector is used – in order to trace reachable objects, we must be able to dynamically determine what is a pointer – reclamation is fast because doing collection on smaller heap – imagine doing this in C! – fragmentation depends on collector used in each heap – easier in Java – how? Further Analysis – compiler support and/or runtime tagging + less memory is required if use mark-sweep for older generations – convention about what can be a pointer + possibly better locality – what if we ’ re not certain about what is a pointer? – still sometimes do full, slow collections (embarrassing pause!) – be conservative; assume anything that may be a pointer is – need to record age with each object – may keep extra garbage – can not move objects (mark-compact) – conservative garbage collectors can be used with C CS553 Lecture Garbage Collection 17 CS553 Lecture Garbage Collection 18 Who does what? Scheduling Garbage Collection “...Performance Impact of Garbage Collection” [Blackburn et al 2004] Generally Experiment setup – allocation is no longer possible, garbage collection is necessary – use Jikes RVM (research virtual machine), highly optimized – VM usually stops all mutator threads – MMtk (The Memory Management Toolkit) is a framework for construction of garbage collectors within Jikes RVM. – JIT generated code must properly handle out-of-memory exception – Machines: Athlon (best performance), Pentium 4, Power PC – Benchmarks: SPEC JVM benchmarks and pseudojbb (variant of SPEC Write barriers (for reference counting and generational collection) JBB2000) – Each time a write to a pointer occurs, a write barrier catches this and – garbage collection algorithms performs some action – semi-space, a copying tracing collector – generation collection needs the write barrier to keep track of pointers from older generations to new generations – mark-sweep – reference counting requires write barriers to detect when any pointer – reference-counting changes CS553 Lecture Garbage Collection 19 CS553 Lecture Garbage Collection 20 5