Simple Generational GC Andrew W. Appel (Practice and Experience, February 1989) Rudy Kaplan Depena CS 395T: Memory Management February 9, 2009

2 Outline Motivation Idea Description Discussion Conclusion References The End

3 Motivation: Goals GC should be ….  Simple to implement Moon [1] requires special hardware [that’s not simple!]  Fast to allocate Use idea that young objects point to old objects Not other way around [that’s not expensive!]  Low cost overhead Algo should be incremental (i.e. - amortize collection cost)

4 Motivation: Mark-Sweep [2] From Vitaly Shmatikov’s Presentation in Spring 2008 on GC [ Heap space root set

5 Motivation: Mark-Sweep [2] From Vitaly Shmatikov’s Presentation in Spring 2008 on GC [ Heap space root set

6 Motivation: Mark-Sweep root set Heap space [2] From Vitaly Shmatikov’s Presentation in Spring 2008 on GC [

7 Motivation: Mark-Sweep root set Heap space Reset mark bit of marked cells Free unmarked cells [2] From Vitaly Shmatikov’s Presentation in Spring 2008 on GC [

8 Motivation: Mark-Sweep Good  Incremental Garbage Reclamation  Cost is amortized Bad  Memory Size Proportional To Time Time Memory Size

9 Motivation: Copying Good  Time Proportional to Number of Reachable Records  No Free List Bad  Can we be faster? Time # of Reachable Records

10 Idea Description: Improvements Two Observations  Pointers are acyclic Newer Records --> Older Records Older Records --> Newer Records a.k.a “assignment” Changing field in previously allocated record  Generational Hypothesis Young objects more likely to become garbage soon Generational GC is a variant of Copying GC Records kept in regions of similar age GC copies reachable objects in A[n] into new area A[n]’ w/o touching other areas

11 Idea Description: Assignment Table Lieberman & Hewitt’s Entry Table  Checking fetched values is done indirectly This is expensive  When region, An, is collected, the whole assignment tables must be examined This is overhead Moon and Ungar provide different alternatives Generational GC not good for PLs that have assignment as main mechanism for changing data structures.

12 Idea Description: Copying Algo Heart of Generational GC  Copy live data from one region (“source region”) to another (“destination region”) Forward Procedure  Copies source to destination and returns pointer  If previously copied, return copy w/o making new copy  Scan pointer successively increments thru destination region until scan catches up with next

13 7 link 9 p q r 37 right 12 left right 15 left 20 left right left right [3] From Mooly Sagiv’s Presentation on Memory Management [ ]

14 7 link p q r 37 right 12 left right left 20 left right left right 15 left scan next [3] From Mooly Sagiv’s Presentation on Memory Management [ ]

15 7 link p q r 37 right 12 left right left 20 left right 59 left right 15 left right 37 left scan next [3] From Mooly Sagiv’s Presentation on Memory Management [ ]

16 7 link 9 p q r 37 right left right left 20 left right left right 15 left right 37 left scan next 12 left right [3] From Mooly Sagiv’s Presentation on Memory Management [ ]

17 7 link 9 p q r 37 right 12 left right left 20 left right left right 15 left right 37 left scan next 12 left right [3] From Mooly Sagiv’s Presentation on Memory Management [ ]

18 Idea Description: Fast Allocation GC never touches garbage Unallocated memory always in contiguous region (i.e. - no free list ) (cons A B) 1.Test free space pointer against free space limit 2.If the limit is reached, call GC 3.Subtract 2 from free space ptr 4.Store A 5.Store B 6.Return current value of free-space pointer

19 Idea Description: Fast Allocation <-- free space ptr <-- free space limit 0xFFFFFFFF 0x

20 Idea Description: Fast Allocation <-- free space ptr <-- free space limit A 0xFFFFFFFF 0x

21 Idea Description: Fast Allocation <-- free space ptr <-- free space limit A B 0xFFFFFFFF 0x

22 Idea Description: Fast Allocation Use Virtual Memory hardware to make comparison  1. Test free-space ptr against free-space limit If we get a page fault from inaccessible page mapped just before free space, we will initiate garbage collection Free space pointer kept in register Instructions to allocate A and B in (cons A B) has little overhead on some platforms (e.g. - AIX)

23 Idea Description: Variable Sized Records Most PLs have various record sizes GC needs to know sizes in order to memory management efficiently. Many ways to do this …  Record can contain tag to explain format  Records of different formats stored in different areas of memory  PL with static type system (e.g.- Haskell, ML) can provide GC with map of type system which explains runtime format.

24 Idea Description: Arranging Generations Unix program break Page 8 on Appel’s “Simple Generational Garbage Collection and Fast Allocation”

25 Idea Description: Arranging Generations Page 9 on Appel’s “Simple Generational Garbage Collection and Fast Allocation”

26 Idea Description: Arranging Generations If program uses at most A words of live data, then size of memory M = 2A For Best performance, M > 2A Invariant  If A < M/2, then GC never runs out of space

27 Please Sir, May I Have Some More?  = ratio of memory size to live data  o = desired value of   < 2, algo will run out of space or degrade performance  ≥ 3 for good performance Ask OS for more space under following circumstances

28 Please Sir, May I Have Some More? Circumstances for request of more memory  After a major collection when  <  o  Collector runs out of space when trying to copy older region to reserve region  After minor collection cycle, free region is not much larger than requested by program.

29 Idea Description: Keeping Track of Assignments The GC uses the root set when it starts collecting the newest area It needs the root set to determine what is reachable We must maintain a list of every record assigned into This list can be maintained in software

30 Idea Description: Keeping Track of Assignments Upon instruction of form “assign p to record r” The compiler will insert “add r to assignment list” Assignment List We May Exhaust free space failing the operation

31 Idea Description: Handling Page Traps When does a Page Trap Happen?  When the mutator runs out of space The allocator tries to make a new record in an inaccessible page, leading to a “seg fault” Seg faults trigger GC Reset the free space pointer to appropriate value, and return from interrupt

32 Idea Description: Handling Page Traps When GC is invoked, roots are  Global Variables  Runtime stack  Machine registers  Assignment list When data is moved from newer to older region, these registers and placeholders get modified

33 Discussion: Space What if runtime system sampled ratio of live data versus total memory over multiple program runs and system consistently used a lot less memory than was available? Could we reduce space waste? What technologies would we be able to apply this technique to? What downfalls could this have?

34 Discussion: Security “The root objects are the entry points for a security [breach] …. The collector would have to access objects at various security levels; this would require the collector to be trusted” - Dieter Gollmann (Computer Security: ESORICS 94) Upon encounter of the assignment operation, we place a record on the assignment linked list.  If there is an “overflow, then more space for it can be allocated or the garbage-collector may be invoked” - Appel, Page 12 Could there be security hole? DOS attack?

35 Discussion: Portability “On a VAX the subtraction from the free-space pointer can be implemented by means of an auto-decrement addressing mode ….. [because] instructions take no more time than any other pair of stores into memory, the overhead attributable to an allocation from the heap is exactly zero” - Appel, 7 Are these portability restrictions necessary, or can we be more portable than this? Could we ever use this type of GC in languages like Java given these portability constraints?

36 Discussion: Portability Would other stack layouts work for this scheme?

37 Discussion: Other Languages How well will this scheme perform on other languages?  JavaScript  C#  etc …

38 Conclusions Generational GC is not for every language and can get expensive on assignments GC becomes fast so overhead of creating object is less than overhead to clean up mess This paper attempts to present simple and efficient arrangements of generational GC, while gaining speed through special instructions and other techniques

39 References [1] David A. Moon, “Garbage collection in a large LISP system,” ACM Symposium on LISP and Functional Programming, pp , ACM, 1984 [2] Vitaly Shmatikov, “Garbage Collection,” The University of Texas at Austin, Spring [3] Mooly Sagiv, “Memory Management”, Tel Aviv University [4] Dieter Gollmann, “Computer Security: ESORICS 94 : Third European Symposium on Research in Computer Security, Brighton, United Kingdom, November 7-9, 1994 : Proceedings