1. Computer Science Department Daniel Frampton, David F. Bacon, Perry Cheng, and David Grove Australian National University Canberra ACT, Australia Daniel.Frampton@anu.edu.au IBM T.J. Watson Research 19 Skyline Drive, Hawthorne, NY 10952, USA bacon, perryche, groved@us.ibm.com Slide Author: Matt Marzilli Generational Real-Time Garbage Collection A Three-Part Invention for Young Objects (ECOOP 2007)

2. 2 Computer Science Department Outline  Generational GC Review  Problems with Synchronous GC  Asynchronous GC Goals  Tri-partite Nursery Collection  Evaluation

3. 3 Computer Science Department Generational Garbage Collection  Generational hypothesis: Most objects have very short lifetimes.

4. 4 Computer Science Department Generational Garbage Collection  Do work proportional to live objects.  Get back space proportional to dead objects.

5. 5 Computer Science Department Generational Garbage Collection  Possible pointer types between regions

6. 6 Computer Science Department Write Barriers  Discover all pointers into nursery from the mature area don’t want to perform O(mature) scan of the entire mature area when collecting just the nursery  Write Barriers keeps track of all pointers from from mature objects to nursery objects a.foo = b; Obviously adding overhead (later known as a remset, REM beginning snapshot during collection)

7. 7 Computer Science Department Why design a Real-Time Garbage Collector?  Frequent object allocation often associated with object- oriented programming  Typically Generational Garbage Collectors (GGC) collect the nursery synchronously application responsiveness coupled to worse case nursery collection time can lead to long (50 ms) pauses for some applications  Nursery size can be a problem collection rate = 100 MB / s, max application pause = 1 ms nursery = 100 KB smaller nursery size => more chance objects will be promoted to mature space, not much benefit from GGC

8. 8 Computer Science Department Real-Time Generational Garbage Collection Goals  Perform nursery collection incrementally  Design should allow nursery collection to occur at any time (even in middle of a mature collection)  Ability to size nursery independently of real-time application bounds still want a nursery large enough to derive GGC benefit  Nursery collection work should be O(nursery) NOT O(heap)

9. 9 Computer Science Department Terminology  Mutator - the application, “mutates” state of the garbage collector’s world via object allocation  M: mature region  N k : k th nursery region  REM k : remset used when k th nursery is collected  ROOT k : root set used when k th nursery is collected

10. 10 Computer Science Department Tri-partite Nursery  Goal: Allow mutators to continue allocating (i.e. executing) during collection of the nursery.  Objects are allocated into a separate nursery while the previous nursery is being collected. Nursery used for allocation, alloc nursery Nursery being collected, collect nursery

11. 11 Computer Science Department Tri-partite Nursery  alloc nursery grows from more and more allocation performed by mutator i.e. no fixed size! grows until nursery trigger has been reached if collect nursery is still being collected alloc nursery must wait to be collected (mutator can still allocate) no flood-gating  A third nursery, the promote nursery, contains forwarding pointers for the previously collected nursery

12. 12 Computer Science Department Tri-partite Nursery

13. 13 Computer Science Department Tri-partite Nursery

14. 14 Computer Science Department Tri-partite Nursery

15. 15 Computer Science Department Tri-partite Nursery Mutators allocate into N2 and contribute remset entries to REM2.

16. 16 Computer Science Department Tri-partite Nursery REM 1  ROOT1 provides a full snapshot of live N 1 object data

17. 17 Computer Science Department Tri-partite Nursery M -> N1 (included in REM2)

18. 18 Computer Science Department Tri-partite Nursery N1 -> N2 (to be promoted in REM2)

19. 19 Computer Science Department Tri-partite Nursery N2 -> N1 (found in next collection)

20. 20 Computer Science Department Tri-partite Nursery  Possible pointers created during N 1 collection:  M  N 1 added to REM2 and traversed in next collection  M  N 2 added to REM2  N 1  N 2 correspond to M  N 2 (when object in N 1 is promoted)  N 2  N 1 discovered at next (N2) collection, reason for promote nursery

21. 21 Computer Science Department Tri-partite Nursery N0 can be reclaimed

22. 22 Computer Science Department Evaluation  Minimum Mutator Utilization (MMU) (Cheng, Belloch) measure of worst case utilization by the mutator (application) over a time window. multiple short pauses grouped closely can be as disruptive as a single continuous pause

23. 23 Computer Science Department Evaluation  Metronome Synchronous nursery collection Real-time incremental using time-based scheduling Incremental Mark-Sweep Snapshot at beginning

24. 24 Computer Science Department Evaluation

25. 25 Computer Science Department Evaluation - Memory Usage Spikes pseudojbb benchmark

26. 26 Computer Science Department Evaluation  Benefits Programs that exhibit generational behavior can derive performance benefits.  Disadvantages Non-generational behavior can lead to performance degradation. Maximum memory usage can trend higher (pseudojbb)

27. 27 Computer Science Department Conclusion  RT GGC can derive performance benefits for programs exhibiting generational allocation patterns, but can also hurt ones that don’t.  Tri-partite nursery can be used to overlap collection and allocation.