1 / 21

Beltway: Getting Around GC Gridlock Steve Blackburn, Kathryn McKinley Richard Jones, Eliot Moss

Beltway: Getting Around GC Gridlock Steve Blackburn, Kathryn McKinley Richard Jones, Eliot Moss. Modified by: Weiming Zhao Oct. 2008. Outline. Motivations & Background Beltway GC framework Subsumes existing copying GC New collectors: Beltway X.X & Beltway X.X.100

fraley
Télécharger la présentation

Beltway: Getting Around GC Gridlock Steve Blackburn, Kathryn McKinley Richard Jones, Eliot Moss

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.

E N D

Presentation Transcript

  1. Beltway:Getting Around GC GridlockSteve Blackburn, Kathryn McKinleyRichard Jones, Eliot Moss Modified by: Weiming Zhao Oct. 2008

  2. Outline • Motivations & Background • Beltway GC framework • Subsumes existing copying GC • New collectors: Beltway X.X & Beltway X.X.100 • Novel mechanisms to make them efficient • Experimental Results • Conclusion

  3. Where is GC? • Renewed interest in GC • Object-oriented languages with automatic memory management (Java, C#) • Major outstanding issues • GC throughput--10 to 70% penalty • Beltway - high throughput with new copying framework • Combing high throughput and low pause times • Ulterior Reference Counting • Understanding & exploiting locality with GC • Dynamically adaptive GC

  4. Object Demographic Observations • Lifetimes • Young objects: Most very short lived • Infant mortality: ~90% die young (within 4MB of alloc) • Old objects: most very long lived (bimodal) • Mature morality: ~5% die each 4MB of new alloc • Pointer mutations • Older to younger pointers across many objects are rare • less than 1% • Most mutations among young objects • 92 to 98% of pointer mutations

  5. 5 Key Ideas in Copying GC • Generational hypothesis (Ungar, Lieberman/Hewitt) • Young objects: most die, so collect frequently • Old objects: most live, so collect infrequently • Older-first principle (Stefanovic/McKinley/Moss) • Give objects as much time to die as possible • Incrementality improves responsiveness • Copying GC can improve locality Can one GC incorporate them all?

  6. Beltway • A new framework for GC algorithms • Subsumes existing copying GCs • Includes new, faster copying GCs • Novelty • Generality • New algorithms • New GC mechanisms

  7. Two Organizational Principles • Increments • Independently collectable regions • Belts • FIFO groupings of increments

  8. Configurations of Beltway

  9. 0 0 1 1 2 3 4 5 6 7 2 1 3 2 4 3 5 4 6 5 7 6 8 7 2 3 4 5 6 7 8 9 A Simple Example Belt Increments • Notice: • Need for copy reserve (rightmost increment) • Incompleteness (w.r.t. cross-increment cycles) • Corresponds to “OF-Mix” GC [Stefanovic 99] • Semi-Space (degenerate form, 2 increments)

  10. etc. etc. … 1 2 3 4 5 6 7 8 2 3 4 5 6 7 8 9 0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7 33 0 34 34 1 35 2 36 3 37 4 38 5 39 6 40 7 35 36 37 38 39 40 41 1 2 3 4 5 6 7 8 • Rules: • Only N increments available (N=8 here) • Must reserve one for copying • Always collectleftmost, lowest full increment A More Interesting Example • Notice: • Generational & older first principles • Still incomplete • This heap organization is Beltway X.X • X is the increment size(e.g. Beltway 20.20 or Beltway 14.14) • Beltway 100.100 = Appel-style generational

  11. 0 1 3 4 5 6 7 8 9 10 33 34 35 36 37 38 39 40 Completeness • Add a third belt (“Beltway X.X.100”) • Large increment (100% of available) • Only collect third belt when it is full • Reduce incrementality, gain completeness

  12. Efficient Implementation • Crucial issues: • Write barrier cost (consequence of incrementality) • Knowing when to collect • Minimizing ‘copy reserve’ overhead

  13. 2n-aligned contiguous virtual memory space • Accommodates an increment* • Allows fast inter-increment w/b 2f 9x2f 10x2f 7x2f 8x2f increment frame New Mechanisms • Frames • Incrementality with cheap w/b • One for each <source, target> frame pair • Dynamic, conservative copy reserve • Only reserve as much as necessary • GC triggers • Don’t necessarily collect only when full • Remembered sets • One for each <source, target> frame pair

  14. Results • Implemented in Jikes RVM with GCTk • Compare to state of the art copying GC - Appel-style generational • Measure over 33 heap sizes • 1.0 through to 3.0 x minimum heap size • GC time • Total execution time • Normalize results to best

  15. Fixed nursery size VS. Appel(geometric mean of 6 benchmarks)

  16. Impact of increment size of Beltway X.X.100(geometric mean of 6 benchmarks) Use 25.25.100 configuration in the remainder of the results

  17. Beltway X.X VS. X.X.100 VS. Appel

  18. Beltway: Conclusions • Beltway: a new framework • New family of GC algorithms • Subsumes existing copying GCs • Opens up new GC possibilities • Generality + efficiency • Better, faster GCs

  19. Remaining Problem: Combining Throughput & Responsiveness

  20. MMU Plots for javac at Two Heap Sizes

  21. Discussion Questions • Worst case space overhead? • Pause time in a 100 belt increment? • Fixed-size increments? • What happens if the remsets get big? • Locality?

More Related