Space Efficient Conservative Garbage Collection Hans-Juergen Boehm, Xerox PARC Presented by Ryan Braud

Garbage Collectors Reclaim storage allocated by a program that is no longer accessible Minimizes the need for explicit memory management Used in languages today like Java, D, Ruby, etc Even as a C/C++ library!

Conservative Garbage Collectors Operate with minimal information about the layout of data Do not rely on compiler provided information about the location of pointers Assumes any bit pattern that could be a pointer actually is

Why Be Conservative? Have been used successfully in large C programs Can be used to debug programs that explicitly deallocate memory Make it possible to easily compile other programming languages that require garbage collection into efficient C

Problems with Conservatism Memory “leakage” in some circumstances Significant amounts of inaccessible memory are not reclaimed Ad hoc solutions exist, but nothing systematic

Pointer Misidentification Most apparent source of excess memory retention Non-pointers incorrectly assumed to be pointers

Pointer Misidentification A* a = new A(); int x = (int)a; a = NULL; x is now a “reference” to a, even though a should be garbage collected a Unaligned accessInvalid reference “Address”

Solution Ensure garbage collections occur at regular intervals “Blacklist” invalid pointers that could become valid addresses in the future Do not allocate objects at or across blacklisted addresses Reclaim blacklisted addresses if they do not appear in a future collection

Blacklisting mark(p) { if p is not a valid object address if p is in the vicinity of the heap add p to blacklist return if p is marked return set mark bit for p for each field q in the object referenced by p mark(q) }

Implementation Details Blacklist entire pages, not individual addresses Implemented as a bit array, one per page For a discontiguous heap, hash table with one bit per entry

Evaluation Ran program T on three different architectures and under PCR Allocates 200 circular linked lists containing 100 Kbytes each, then assigns head of each list to 0 Compared amount of unclaimed memory with that of non-blacklisting garbage collector Collector configured such that any “reference” to any of the 100,000 addresses in a list causes entire list to be retained

Results MachineOptimized?No BlacklistingBlacklisting SPARC(s)No %0-.5% SPARC(s)Yes %.5-1% SPARC(d)No8-9.5%.5% SPARC(d)Yes9-11.5%0-.5% SGI(s)No1.5-8%0% SGI(s)Yes1-4%0% OS/2(s)No28%3% OS/2(d)Yes26%1% PCRMixed % %

Conclusions Blacklisting an effective technique in reducing longterm accidental storage retention Easy to implement and only approx. 1% slowdown vs non-blacklisting garbage collector