1 / 21


Hans-Juergen Boehm Computer Science Dept. Rice University, Houston Mark Wieser Xerox Corporation, Palo Alto Presented by Srilakshmi Swati Pendyala. GARBAGE COLLECTION IN AN UNCOOPERATIVE ENVIRONMENT. Outline. Introduction Garbage Collection In Different Languages Problem Domain

Download Presentation


An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.


Presentation Transcript

  1. Hans-Juergen Boehm Computer Science Dept. Rice University, Houston Mark Wieser Xerox Corporation, Palo Alto Presented by Srilakshmi Swati Pendyala GARBAGE COLLECTION IN AN UNCOOPERATIVE ENVIRONMENT

  2. Outline • Introduction • Garbage Collection In Different Languages • Problem Domain • Need for conservative garbage collection in uncooperative environments • Overview of the proposed Garbage Collector • Use of the proposed GC as a debugging tool • Implementation Results • Conclusion

  3. Introduction • Garbage Collection Different Languages ? • JAVA http://www.folgmann.com/en/gc.html

  4. Introduction • Garbage Collection Different Languages : • .NET, VB, C# ? • Perl , Python ? • C, C++ ?

  5. Introduction • Garbage Collection Different Languages ? • .NET, VB, C# – Mark and Sweep, Generational • Perl , Python – Reference Counting • C, C++ – No garbage collection, managed options available. • ADA, Modula 3 – Manual & Automated Garbage Collection

  6. Introduction • JAVA, .NET etc. • Automatic Garbage Collection • No memory management effort for the programmer • In the run-time, the program should tell the GC which memory objects are still in use • C, C++ etc. • Program should “free” the allocated memory • Prone to memory leaks etc. • Both cases lead to additional effort from program/compiler. • GC affects the performance of the program • Better performance can be achieved (in some cases) when the program doesn’t worry about GC at all.

  7. What is the need to avoid cooperation? • Programmers don’t want to pay for GC unless needed • Disadvantage in tagging the integers • Reduction available number of bits • Difficulty in manipulating standard machine representation of data. • Need for interfacing routines • To implement specific programming language like Russell • To enable garbage collection in conjunction with C, Pascal etc. • Difficult to design compilers that always preserve garbage collection invariants Need for a Garbage Collector that expects less from the program/compiler

  8. Uncooperative Environment • Program/compiler does not provide information to recognize pointers • Every register/word potential pointer • All the storage that is accessible by the stack, registers etc., may not be needed by the program • Compiled code may fail to destroy the references (for performance issues/because of bugs) • Particular run-time representations may involve unnecessary references not intended by the programmer • Difficult to tell if an object is actually required by the program • Can lead to program failure if necessary objects are deleted • Need for CONSERVATIVE Garbage Collection

  9. Conservative Garbage Collection • Imagine doing a mark and sweep GC, but not knowing for sure if a cell has a pointer in it or some other data. • If it looks like a pointer (that is, is a valid word-aligned address within heap memory bounds), assume that it IS a pointer, and trace that and other pointers in that record too. • Any heap data that is not marked in this way is garbage and can be collected. (There are no pointers to it.)

  10. Discussion • Is conservative Garbage Collection needed in Cooperative systems ? • Disadvantages of Conservative Garbage Collection ? • Some amount of inaccessible memory is not reclaimed. • How can we reduce memory lost because of Conservative Garbage Collection ? • Better checks to detect false pointers

  11. How does the Garbage Collector work? • Uses Mark-Sweep Stop-the-World Garbage Collection Algorithms • Procedure: • Scan all objects referenced directly by pointer variables (roots) from stack & registers • Verify that pointers are actually pointing to intended objects (validity check) and mark the objects referenced by validated pointers • Mark objects directly reachable from newly marked objects. • Finally identify unmarked objects and free them (sweep) • E.g. put them in free lists. • Reuse to satisfy allocation requests. • Objects are not moved.

  12. Mark/Sweep illustration Stack w/ pointer variables

  13. Mark/Sweep illustration (2) Stack w/ pointer variables

  14. Allocator design • Allocation scheme obtains “chunks” of memory. • Chunks are always multiples of 4k in size. • Separate free lists for each object size. • Characteristics: • No per object space overhead (except mark bits) • Partial sweeps are possible.

  15. Heap layout Heap Data Free lists . . . 4k size chunks

  16. Data Structure for Chunks • A list of allocated chunks contains pointers to the beginning of each chunk • Contents of a chunk C: • Size of objects in the chunk • A pointer to the entry for C in list of allocated chunks • An area reserved for mark bits corresponding to the objects in the chunk • Data Objects Is it better than “tagging” integers ?

  17. Finding Roots & Pointers • Possible roots: registers, stack, static areas • No cooperation from compiler • treat every word as potential pointer • ignore interior pointers (standard) • prefer marking from false pointers over ignoring valid pointers Conservative Pointer Identification: given word p; • does p refer to the collected heap? • does it point into heap block allocated by collector? • does it point to the beginning of an object in that block? if yes, • mark object in block header • push object onto mark stack • Sweep: • If a chunk is completely empty, return it to the chunk allocator

  18. Pointer Validity Check Goal: To minimize the marking of false pointers • The pointer “p” should reference to a proper heap-address range for it to correspond to an object • If it corresponds an object, the pointer contained in the chunk header should correspond to the actual address of pointer “p” in the list of allocated chunks • The offset of the supposed object from the chunk header should be a multiple of of the object size given by chunk header and it should be within the end of the chunk

  19. Garbage Collector as a Debugging Tool • Use GC to identify allocated memory that is no longer needed by the program, but not yet freed by it. • Use a tracer to track the memory leaks back to the subroutine responsible for them. • Procedure: • An allocation-and-free tracer. • Subroutine names are recorded on a stack with every call to “malloc”. • Mark the storage as freed when ‘free’ calls are made. • When collector runs, storage having no pointers to it and that was never explicitly deallocated with ‘free’ call is likely for storage leak. • Collector running with the tracer could find most of the storage unmarked by the collector, but never been explicitly “free”d.

  20. Experimental Results • Mark phase of Russell collector took 1.9 seconds per megabyte of accessible memory in the heap. Sweep phase took 0.4 seconds per megabyte. • Garbage Collection was added to TimberWolf and SDI. • The systems were re-linked so that calls to Unix allocation routines instead called the allocator. • SunView presented problems because of dynamic allocated memory remapping and ‘notifier’. • Programming styles involving disguised pointers will not work with the collector method. • Use of the proposed GC as debugging tool has also been demonstrated on SunView system.

  21. Conclusions • GC effective for traditional imperative languages with minimum cooperation from program/compiler • Realistic alternative to explicit memory management for most applications • May not suitable for real-time applications • No big constraints to coding style, except hidden pointer problem • GC’ing allocators competitive even with code not written for GC • The same GC can be used as debugging tool for programs that do manual garbage collection • An implementation of this garbage collector can be downloaded online

More Related