1. 1 Compiler Construction (CS-636) Muhammad Bilal Bashir UIIT, Rawalpindi

2. Outline 1. Introduction to Garbage Collection 1. Design Goals for Garbage Collectors 2. Reachability 3. Reference Counting Garbage Collectors 2. Summary 2

3. Run-Time Environments Lecture: 25-26 3

4. Introduction to Garbage Collection Data that cannot be referenced is generally known as garbage Many high-level programming languages remove the burden of manual memory management from the programmer by offering automatic garbage collection Garbage collector deallocates unreachable data The notion of an object being “reachable” is perhaps intuitive so we need precise rules to declare an object as reachable or unreachable 4

5. Introduction to Garbage Collection (Continue…) Garbage collection dates back to the initial implementation of Lisp in 1958. Languages that offer garbage collection include Java, Perl, ML, Modula-3, Prolog, and Smaltalk Many language cannot offer garbage collection due to their method of managing types 5

6. Design Goals for Garbage Collectors Garbage collection is the reclamation of chunks of storage holding objects that can no longer be accessed by a program We need to assume that objects have a type that can be determined by garbage collector at run time The type tells how large the object is and which components of the object contain references (pointers) to other objects We also assume that references to objects are always to the address of the beginning of the object, never pointers to places within the object 6

7. Design Goals for Garbage Collectors (Continue…) If references point to the beginning of the address, it makes sure that all references have same values A user program, which we shall refer to as mutator, modifies the collection of objects on heap The mutator creates objects by acquiring space from the memory manager and mutator may intrduce or drop references to existing objects Objects become garbage when mutator program cannot reach them The garbage collector finds such unreachable objects and reclaim their space 7

8. Design Goals for Garbage Collectors (Continue…) A Basic Requirement: Type Safety Not all languages are good candidates for automatic garbage collection For a garbage collector to work, it must be able to tell whether any given data element or its component is, or could be used as, pointer to a chunk of allocated memory space A language in which the type of any data component can be determined is said to be type safe  There are type-safe languages like ML, for which we can determine types at compile time 8

9. Design Goals for Garbage Collectors (Continue…) There are other type-safe languages, like Java, whose types cannot be determined at compile time, but can be determined at run-time  These languages are dynamically typed languages If a language neither statically nor dynamically type safe, then it is said to be unsafe Unsafe languages e.g. C and C++, are bad candidates for automatic garbage collection because memory addresses can be manipulated  Arbitrary arithmetic operations can be performed on pointers to form new pointers 9

10. Design Goals for Garbage Collectors (Continue…) In C and C++, theoretically a program could refer to any location in memory at any time Consequently, no memory location can be considered as inaccessible, and no storage can ever be reclaimed safely Despite the inherent problem in C/C++, an unsound garbage collector has been developed for these languages also and experiments have shown good results about its working 10

11. Design Goals for Garbage Collectors (Continue…) Performance Metrics Garbage collection is often so expensive that, although it was invented decades ago & absolutely prevents memory leaks, it has yet to be adopted by many mainstream programming languages Many different approaches have been proposed but still there is not one clearly best garbage-collection algorithm There are many performance metrics that should be considered while designing a garbage collector 11

12. Design Goals for Garbage Collectors (Continue…) Overall Execution Time  Garbage collection can be very slow so it is important that it not significantly increase total run time of an application Space Usage  It is important that garbage collection avoids fragmentation and makes good use of the available memory Pause Time  Garbage collectors kicks in without warning and they are notorious of causing programs – the mutators – to pause suddenly for extremely long time. So it is desirable that the pause time is minimized. For real time applications we may avoid running garbage collection or restrict max pause time 12

13. Design Goals for Garbage Collectors (Continue…) Program Locality  We cannot evaluate speed of a garbage collector solely by its running time. The garbage collector controls the placement of data and thus influences the data locality of the mutator program Some of these design goals conflict with one another, and tradeoffs must be made carefully by considering how programs typically behave Also objects of different characteristics may have different treatments so garbage collector should handle them accordingly 13

14. Reachability We refer to all the data that can be accessed directly by a program without having to dereference any pointer, as the root set  For example, in Java the root set of a program consists of all the static field members and all the variables on its stack A program can reach any member of its root set at any time Recursively any object with a reference that is stored in the field members or array elements of any reachable object is itself reachable 14

15. Reachability (Continue…) The reachability becomes a bit more complex when the program has been optimized by the compiler The set of reachable objects changes as a program executes It grows as new objects created and shrinks as objects become unreachable It is important to remember that once an object becomes reachable, it cannot become reachable again There are four basic operations that mutator performs to change the set of reachable objects 15

16. Reachability (Continue…) 1. Object Allocations  These are performed by memory manager, which returns a reference to each newly allocated chunk of memory. This operation adds members to the set of reachable objects 2. Parameter Passing & Return Values  References to objects are passed from the actual input parameter to the corresponding formal parameter, and from the returned result back to the callee. Objects pointed to these references remain reachable 16

17. Reachability (Continue…) 3. Reference Assignment  Assignments of the form u = v, where u and v are references, have two effects.  First, u is now reference to the object referred to by v. As long as the u is reachable, the object it refers to is surely reachable  Second, the original reference in u is lost. If this reference is the last to some reachable object, then that object becomes unreachable.  Any time an object becomes unreachable, all objects that are reachable only through references contained in that object also become unreachable 17

18. Reachability (Continue…) 4. Procedure Returns  As a procedure exits, the frame holding its local variables is popped off the stack. If the frame holds the only reachable reference to any object, that object becomes unreachable. Again, if the now unreachable objects hold the only reference to other objects, they too become unreachable, and so on. 18

19. Reachability (Continue…) There are two basic ways to find unreachable objects First, we catch the transitions as reachable objects turn unreachable  Reference counting is a well-known approximation to this approach Second, we periodically locate all the reachable objects and then infer that all the other objects are unreachable  A trace-based garbage collector is built on this approach 19

20. Reference Counting Garbage Collectors This garbage collector is based on technique reference counting, which identifies garbage as an object changes from being reachable to unreachable, the object can be deleted when the count drops to zero With a reference-counting garbage collector, every object must have a field for the reference count Reference count can be maintained as follows 1. Object Allocation  The reference count to the new object is set to 1 20

21. Reference Counting Garbage Collectors (Continue…) 2. Parameter Passing  The reference count of each object passed into a parameter is incremented 3. Reference Assignments  For statement u = v, where u and v are references, the reference count of the object referred to by v goes up by one and the count of the old object referred to by u goes down by one 21

22. Reference Counting Garbage Collectors (Continue…) 4. Procedure Returns  As the procedure exits, all the references held by the local variables of that procedure activation records must also be decremented. If several local variables hold the reference to same object, that object’s count must be decremented once for each such reference 5. Transitive Loss of Reachability  Whenever reference count of an object becomes zero, we must also decrement the count of each object pointed to by a reference within the object 22

23. Reference Counting Garbage Collectors (Continue…) Reference counting has two main disadvantages 1. It cannot collect unreachable cyclic data structures 2. This approach is expensive Cyclic data structures are plausible  Data structures often point back to their parent nodes  Data structures point to each other as cross reference 23

24. Reference Counting Garbage Collectors (Continue…) Consider the figure below;  There are three objects with references to each other but no reference from anywhere else  If none of these are part of root set then they are all garbage but since their reference count is greater than 0, the reference counting garbage collector will not delete them 24

25. Reference Counting Garbage Collectors (Continue…) The overhead of reference counting is high because additional operations are introduced with each reference assignment, and at procedure entries and exits This overhead is proportional to the amount of computation in the program The advantage of reference counting on the other hand is that garbage collection is done in an incremental fashion Even though the overhead may be large, operations are spread throughout the mutator’s computation 25

26. Reference Counting Garbage Collectors (Continue…) Although removing one reference may render a large number of objects unreachable, the operations of recursively modifying reference counts can easily be deferred and performed piecemeal across time Reference counting is particularly attractive algorithm when timing deadlines must be met as well as for interactive applications, where long sudden pauses are unacceptable 26

27. 27 Summary Any Questions?