A RealTime Garbage Collector with Low Overhead and

A Real-Time Garbage Collector with Low Overhead and Consistent Utilization David F. Bacon, Perry Cheng, and V. T. Rajan IBM T. J. Watson Research Center Presented by Jason Van. Fickell thanks to Srilakshmi Swati Pendyala for 2009 slides

Motivation • Real-time systems growing in importance • Desirability of higher level programming languages • Constraints for Real-Time Systems o o Hard constraints for continuous performance (Low Pause Times) Memory Constraints (less memory in embedded systems) Need for a real-time garbage collector with low memory usage. • Maximum Pause Time < Required Response • CPU Utilization sufficient to accomplish task o Measured with Minimum Mutator Utilization • Memory Requirement < Resource Limit o Important Constraint in Embedded Systems

Problems with Previous Works • Fragmentation Early works (Baker’s Treadmill) handles a single object size Fragmentation not a major problem for a family of C and C++ benchmarks (Johnstone’ Paper) § Unsustainable for long-running programs o Use of single (large) block size § Increase in memory requirements and internal fragmentation o o • High Space Overhead o Copying algorithms to avoid fragmentation increase space overhead o o o Fraction of processor devoted to mutator execution Copying algorithms suffer from uneven mutator utilization Long low-utilization periods • Uneven Mutator Utilization • Inability to handle large data structures

Components and Concepts in Metronome • Segregated free list allocator o Geometric size progression limits internal fragmentation o Objects are usually not moved. o Moves objects to a new page when page is fragmented due to GC • Mostly non-copying • Defragmentation • Read barrier: to-space invariant [Brooks] o New techniques with only 4% overhead o Mark phase fixes stale pointers • Incremental mark-sweep collector • Arraylets: bound fragmentation, large object ops New • Time-based scheduling Old

Segregated Free List Allocator • Heap divided into fixed-size pages • Each page divided into fixed-size blocks • Objects allocated in smallest block that fits 12 16 24

Limiting Internal Fragmentation • Choose page size P and block sizes sk such that o sk = sk-1(1+ρ) • How do we choose small s 0 & ρ ? • s 0 ~ minimum block size • ρ ~ sufficiently small to avoid internal fragmentation Too small a ρ leads to too many pages and hence a wastage of space, but it should be okay for long running processes o Too large a ρ leads to internal fragmentation o • Memory for a page should be allocated only when there is at least one object in that page.

Defragmentation • When do we move objects? o At the end of sweep phase, when there are no sufficient free pages for the mutator to execute, that is, when there is fragmentation • Usually, program exhibits locality of size o Dead objects are re-used quickly o o Dead objects are not re-used for a GC cycle Free pages fall below limit for performing a GC o Major improvement over copying collector • Defragment either when • In practice: we move 2 -3% of data traced

Read Barrier: To-space Invariant • Problem: Collector moves objects (defragmentation) o Mutator is finely interleaved o o o Each object contains a forwarding pointer [Brooks] Read barrier unconditionally forwards all pointers Mutator never sees old versions of objects • Solution: read barrier ensures consistency • Will the mutator utilization have any effects because of the read barrier ? X X Y A Z Y A A′ Z BEFORE Fromspace To-space AFTER

Read Barrier Optimization • Previous studies: 2040% overhead [Zorn, Nielsen] • Several optimizations applied to the read barrier and reduced the cost over-head to <10% using Eager Read Barriers • “Eager” read barrier preferred over “Lazy” read barrier.

Incremental Mark-Sweep • Mark/sweep finely interleaved with mutator • Write barrier: snapshot-at-the-beginning [Yuasa] o o Ensures no lost objects Treats objects in write buffer as roots o o Marker always traces correct object Simpler interleaving • Read barrier ensures consistency

Pointer Fix-up During Mark • When can a moved object be freed? o When there are no more pointers to it o Redirects forwarded pointers as it marks them o At the end of mark phase of collection n+1 • Mark phase updates pointers • Object moved in collection n can be freed: X Y A A′ Z Fromspace To-space

Arraylets • Large arrays create problems o o Fragment memory space Can not be moved in a short, bounded time o Access via indirection; move one arraylet at a time • Solution: break large arrays into arraylets A 1 A 2 A 3

Program Start Stack Heap (one size only)

Program is allocating Stack Heap free allocated

GC starts Stack Heap free unmarked

Program allocating and GC marking Stack Heap free unmarked or allocated

Sweeping away blocks Stack Heap free unmarked or allocated

GC moving objects and installing redirection Stack Heap free evacuated allocated

2 nd GC starts tracing and redirection fixup Stack Heap free evacuated unmarked or allocated

2 nd GC complete Stack Heap free allocated

Scheduling the Collector • Scheduling Issues o o Poor CPU utilization and space usage Loose program and collector coupling • Competing options: o Time-Based § Trigger the collector to run for CT seconds whenever the mutator runs for QT seconds o Work-Based § Trigger the collector to collect CW work whenever the mutator allocate QW bytes

Scheduling Time – Based • Very predictable mutator utilization • Memory allocation does not need to be monitored. Work – Based • Uneven mutator utilization due to bursty allocation • Memory allocation rates need to be monitored to make sure real-time performance is obtained

Experimental Results • IBM RS/6000 Enterprise Server F 80 • AIX 5. 1 • 500 MHz Power. PC RS 64 III • 4 GB RAM • 4 MB of L 2 cache • Jikes Research Virtual Machine (RVM) 2. 1. 1 • Adaptive compilation disabled

Pause Time Distribution for javac (Time-Based vs. Work-Based) 12 s

Utilization vs. Time for javac (Time-Based vs. Work-Based) 0. 45

Minimum Mutator Utilization for javac (Time-Based vs. Work-Based)

Space Usage for javac (Time-Based vs. Work-Based)

Conclusions • The Metronome provides true real-time GC o First collector to do so without major sacrifice § Short pauses (12. 4 ms) § Copying limited to 4% overhead § High MMU during collection (50%) § Low memory consumption (2. 5 x max live) • Critical features o o o Time-based scheduling Hybrid, mostly non-copying approach Integration with the compiler

Discussion • What are the downsides of incremental real-time collection? • What is preserved that Baker's algorithm does not? • Was the architecture used for the experiments appropriate? • Were the performance characteristics adequately explored?