Reducing Generational Copy Reserve Overhead with Fallback Compaction
Reducing Generational Copy Reserve Overhead with Fallback Compaction. Phil McGachey and Antony L. Hosking June 2006. Overview. Background Algorithm Design Implementation Details Experimental Results. Generational Collectors. Generational Hypotheses: Most objects die young
Reducing Generational Copy Reserve Overhead with Fallback Compaction
E N D
Presentation Transcript
Reducing Generational Copy Reserve Overhead with Fallback Compaction Phil McGachey and Antony L. Hosking June 2006
Overview • Background • Algorithm Design • Implementation Details • Experimental Results
Generational Collectors • Generational Hypotheses: • Most objects die young • Older objects less likely to die • Generational collectors exploit this • Allocate to a nursery space • Move older objects to a separate mature space • Most collections don’t look at old objects
Appel’s Collector Mature Copy Reserve Copy Reserve Nursery Nursery
Mature Copy Reserve Nursery Appel’s Collector Mature Copy Reserve Nursery
Copy Reserve • Copying collectors require copy reserve • Must be large enough for the worst case • Most objects do not survive a collection • Optimize the common case
Mature Copy Reserve Nursery Common Case Mature Copy Reserve Nursery
Mature Copy Reserve Nursery Worst Case Mature Copy Reserve Nursery
Design Summary • Based on Appel’s collector • Reduce the copy reserve size • The majority of collections work as normal • Use compaction in the worst case • More efficient use of space • Fewer collections required
Implementation Details • Jikes RVM and MMTk • Modified version of GenCopy collector • Slight differences from Appel’s design
Block Copying • MMTk designates space by virtual address • Must copy objects between spaces • No efficient block copy mechanism • Use mmap() to move pages • Map pages from named backing store • Use offset to refer to block • Unmap and remap as required
Compacting Collector • Difficulty in sweeping immortal spaces • Unreachable objects still in place • Need to modify object scanning • Cannot allocate memory • Heap is already full • Makes forwarding pointers difficult to track • Jonkers’ reference chaining algorithm
Metrics • Vary copy reserve size and heap size • Measure elapsed time for execution • Count major and minor garbage collections
Methodology • Use selected SPECjvm98 benchmarks • Run 11 times • First run compiles with optimizing compiler • Measure remaining ten • Experimental Platform: • Intel Pentium 4/2.26 GHz • 512 Mb RAM • Mandrake Linux 9.2
Summary • New collector with reduced copy reserve • Uses compaction to handle worst case • Several interesting implementation details • Copy reserve size selection important • Performance comparable to or better than other collectors