2. ® July 21, 2004GC Summer School1 Cycles to Recycle: Copy GC Without Stopping the World The Sapphire Collector Richard L. Hudson J. Eliot B. Moss Originally in Java Grande conference, 2001; Now in Concurrent and Computation: Practice and Experience, 2003

3. ® July 21, 2004GC Summer School2 Overview Short review of traditional GC algorithms Sapphire ä Benefits ä Strategy and why the algorithm works ä Mark phase of algorithm ä Copy phase ä Repoint phase ä Flip phase Experimental results Conclusions

4. ® July 21, 2004GC Summer School3 Roots Reachable Objects Garbage How Generational Copy Collection works (Liebermann &Hewitt ’83, Ungar ‘84) Heap Focus Area Problem: -Application threads stopped during GC

5. ® July 21, 2004GC Summer School4 Roots Reachable Objects Reclaimed Generational Continued Copy from Focus Area to New Area Benefits: - no fragmentation - low average latency Garbage

6. ® July 21, 2004GC Summer School5 Sapphire Practical: no read barrier Concurrent: no application thread blocks for GC or another application thread Copy collector: no fragmentation; cache optimizations enabled Scales on shared memory multiprocessors Build and measure

7. ® July 21, 2004GC Summer School6 GC Scalability CPU 0 CPU 1 CPU 2 CPU N app running gc running Traditional GC Algorithms - suspends app threads for time “z” while GC is run - no cpu running application - parallel GC still blocks app Sapphire GC Algorithm - GC thread works for time “z” - application threads pause briefly to process their stacks - only one cpu not running application z app blocked

8. ® July 21, 2004GC Summer School7 Sapphire Collection Strategy Locate reachable objects ä Asking threads for stack roots Make new version of reachable objects Use write barrier to update both versions Point uncollected part of heap at new versions Flip threads to new versions one at a time Repeat

9. ® July 21, 2004GC Summer School8 Locate Reachable Objects Tricolor approach Objects start white, roots start gray Gray objects scanned and turned black Scanning darkens objects: white to gray Empty gray set means white set is garbage Write barrier: ä Don’t create black to white pointer ä Darkening referent object prevents b  w pointer Termination (wave front proof) ä Scan stacks until all scanned with no new gray objs

10. ® July 21, 2004GC Summer School9 Mark Phase Install mark phase write barrier ä Maintain normal generational write barrier ä Install no pointer to white object ä Initializing stores gray white referents ä Stacks are considered to be gray: no write barrier on stack stores (performance issue) Termination (wave front algorithm) ä Scan each stack in turn until we have made a full pass with all stacks scanned without any new gray objects

11. ® July 21, 2004GC Summer School10 C U S S Scan stacks and Heap Thread 1 Thread 2

12. ® July 21, 2004GC Summer School11 Old U S S Allocate new objects, maintain dynamic consistency New

13. ® July 21, 2004GC Summer School12 Old U S S Copy contents updating pointers New

14. ® July 21, 2004GC Summer School13 Dynamic Consistency Copies kept synchronized Write barrier updates both copies of object ä Updates all values, not just pointers ä Never installs pointer to an old object Uses programming language semantics ä Threads need to be up to date only at synchronization program points ä Volatile field accesses handled specially: requires more synchronization for proper r/w ordering

15. ® July 21, 2004GC Summer School14 Repoint Heap Phase Write barrier prevents any old pointers from being written into heap Each update is progress Terminates since no old pointers are added to heap and GC eventually updates all slots

16. ® July 21, 2004GC Summer School15 Old U S S Repoint Heap New

17. ® July 21, 2004GC Summer School16 Thread See Both Old and New Thread can read old pointers but can write only new pointers Equality needs to ensure that old == new for the same object ä Not an issue for comparison with NULL ä Does require a modest compiler change

18. ® July 21, 2004GC Summer School17 Thread Flip Phase Write barrier still prevents writing old pointers, maintains dynamic consistency Suspend and flip threads one at a time ä Resume thread before moving to next thread Once flipped, thread can’t get old pointer ä None in uncollected heap area ä None in new collected heap area ä Can’t read other thread’s stack ä Can’t read old collected heap area Terminates once each thread is flipped

19. ® July 21, 2004GC Summer School18 Old U S S Thread flip New

20. ® July 21, 2004GC Summer School19 Old U S S Thread flip New

21. ® July 21, 2004GC Summer School20 Reclaiming Old Phase New threads only see new area Once all threads are flipped, reclaim old area Algorithm is orthogonal to how collected area is selected ä Lays on top of classic Train algorithm, generational collection, or whatever Once all threads are flipped, write barrier can revert to simple write barrier

22. ® July 21, 2004GC Summer School21 Old U S S Release old area New

23. ® July 21, 2004GC Summer School22 Prototype Implementation / Results Runs performed on Intel’s Open Runtime Platform Goal was to validate the algorithm (little tuning effort) Benchmark programs ä One – one thread allocating, one running GC Allocates 3.2 Gb of objects ä Five – five threads allocating, one running GC Allocates 16 Gb of objects ä Deep – One with 1000 frames on stack Dual 300 Mhz with 512Kb cache and 256Mb memory NT Workstation 4.0 128Mb heap size

24. ® July 21, 2004GC Summer School23 Application Pause Time (microseconds)

25. ® July 21, 2004GC Summer School24

26. ® July 21, 2004GC Summer School25 Sapphire Review Practical: no read barrier Concurrent: no application thread blocks for GC or another application thread Copy collector: no fragmentation; cache optimizations enabled Scales on shared memory multiprocessors Built and measured Needs to be tuned