Garbage Collection

Garbage Collection

1. In writing the various phases of the compiler project, you will find yourself spending a good bit of time making sure you "free" memory areas that were no longer in use:

   • You should have already realized that you have to think a bit about when to free operand descriptors.

     • This may be interesting because some operand descriptors (those for A5 and A6 for example) are referenced from many places and can't be freed when one reference to them is destroyed.

     • In an optimizing compiler that recognized common sub-expressions, any operand descriptor might have multiple references making the decision when to free quite complicated.

2. If we were writing compilers in Java, this just would not be an issue.

   • While Java has a "new" operation that allocates storage much like C's "malloc", there is no "free".

   • The Java compiler and run-time system automatically find and recover dynamically allocated values that are no longer accessible.

3. This approach to dynamic memory management has been standard in applicative languages (LISP, ML, Miranda, Haskell, etc.) for years (forever?). It makes programming simpler, safer, but possibly less efficient.

4. Garbage collection is the process of automatically reclaiming dynamically allocated memory areas.

5. The area in which dynamically allocated memory resides is called the "heap".

6. Before we worry about how to automatically deallocate space from a heap, lets talk about some simple ways to organize a heap and allocate space as needed.

   Free lists

   Have allocated and available areas of memory intermixed with the unallocated units linked together on a "free list".

   Free/used regions

   Maintain a register/variable pointing to the moving boundary between the allocated and unallocated regions of memory. Note: In this scheme the "allocated" region will consist of intermixed used and un-used (i.e. garbage) words.

7. The "free list" idea works best if all the units of memory allocated are of the same size. This was true in the first significant language whose implementation relied heavily on garbage collection, LISP.

8. A dynamically allocated data structure in the heap can be safely disposed and its memory space reused only if it can no longer be accessed. This is true when no variable or method parameter ( or hidden temporary) or other accessible dynamically allocated object refers to it. Thus, to find the garbage we must find the stuff that can't be found!

   • The trick is that we can find out what can't be found by finding out what can be found.

   • The variables, method parameters and hidden temporaries are referred to as "roots". We must search for findable objects starting at each root.

     So, the "main program" of a garbage collector might look like:

          for each record in heap do   
                    record->alreadyfound = false 
          for each root do findThings( root )
     

   • Once an object is found, we must recursively "find" all the objects it points to. So, the "findThings" pseudo-code looks something like a "careful" tree traversal:

     findThings( root )
       {
         if ( root != NULL  &&  ! root->alreadyfound )
            then {  root->alreadyfound = TRUE;
                    for all ``child''ren of root do
                       findThings(  child )
                  }
       }
     

9. The next question is what to do when we find things. Two common answers:

   Mark-scan

   Just set a bit to mark the items as "found" as suggested in the code above. Then later make a pass through the whole heap and identify anything that isn't marked as "unfindable" stuff that can be reused.

   Copying

   Move everything found to a new, unused heap space (and update all pointers to refer to the new copies). When this is all done, the new heap will have used and free space but no garbage.

10. Mark-scan garbage collection was developed for the implementation of LISP where all objects were of the same size. So, as the heap was scanned for free areas they could just be added to the free list.

11. So, to make this all work, we have to plan the layout of data in memory in a way that will let us:

    • Find all the roots.

    • Find all the pointers within a record once we find the record in the heap.

    • Avoid copying things twice.

    • Know where each object has been moved to

    • Update all pointers during copying.

12. The simplest approach to most of these requirement is to "tag" each object and/or pointer with a "descriptor" (sometimes one bit is enough) that will tell the garbage collector what it is.

    • To find all the pointers in a record, we at least need to know how big the record is. So, the first "descriptor" we might use is a length field at the start of each record in the heap.

    • Because a record may contain both pointers and non-pointer values, we either need a descriptor for the whole record or descriptors for each element.

      • This can be done by multiplying all integer values by 2 (so their low order bits will be 0) and making sure that all records are allocated on odd addresses (so that pointers will have 1's in their low order bits).

      • Addition and subtraction can ignore the factor of 2. After each multiplication, you will need to divide the result by 2....

      • On the 34000 this would be costly ( wastes one out of 16 bits and words on the heap), but on real machines it works very well (1 out of 32 bits isn't bad, and on many machines all records have to be stored on odd or even byte addresses anyway).

    • We also need some way to tag a record that has already been moved. Since its contents are not important after it has been moved, there are plenty of ways to handle this (set its length to 0?).

Garbage Collection