An On-the-Fly Mark and Sweep Garbage Collector Based on Sliding Views Hezi Azatchi - IBM Yossi Levanoni - Microsoft Harel Paz – Technion Erez Petrank – Technion

Erez PetrankGC via Sliding Views2 Garbage Collection Today Today’s advanced environments: multiprocessors + large memories Dealing with multiprocessors Stop The World

Erez PetrankGC via Sliding Views3 Garbage Collection Today Today’s advanced environments: multiprocessors + large memories Dealing with multiprocessors Concurrent collectionParallel collection On-the-fly collection

Erez PetrankGC via Sliding Views4 Garbage Collection Today Today’s advanced environments: multiprocessors + large memories Dealing with multiprocessors Concurrent collectionParallel collection On-the-fly collection Informal pause times 3ms 300ms 30ms

Erez PetrankGC via Sliding Views5 Garbage Collection Today Today’s advanced environments: multiprocessors + large memories Dealing with multiprocessors Concurrent collectionParallel collection On-the-fly collection Informal throughput loss 10%

Erez PetrankGC via Sliding Views6 This Talk 1. A new on-the-fly mark and sweep collector. A synergy of snapshot collection and sliding views. 2. Implementation and measurements on the Jikes RVM. Pause times < 2ms Throughput loss 10%.

Erez PetrankGC via Sliding Views7 The Mark-Sweep algorithm [McCarthy 1960] Traverse & mark live objects. White objects may be reclaimed. globals Roots

Erez PetrankGC via Sliding Views8 Base: a snapshot collection A naïve collector: Stop program threads Create a snapshot (replica) of the heap Program threads resume Trace replica concurrently with program Objects identified as unreachable in the replica may be collected. Problem: taking a replica of the heap is not realistic

Erez PetrankGC via Sliding Views9 Base: a snapshot collection A naïve collector: Stop program threads Create a snapshot (replica) of the heap Program threads resume Trace replica concurrently with program Objects identified as unreachable in the replica may be collected. [Furusou et al. 91]: use a copy-on-write barrier. No need to copy unless area written Use virtual pages.

Erez PetrankGC via Sliding Views10 Some inefficiencies Copying a page requires synchronization. Efficiency depends on the system. Triggering and copying apply to all fields although only pointers are interesting: Programs work at object level, this mechanism works at page level a waste to copy a full page.

Erez PetrankGC via Sliding Views11 Synergy with recently developed techniques Note goal: we want to copy pointers in each modified object prior to its first modification. The write barrier of the Levanoni-Petrank reference counting collector provides exactly this. Use a dirty bit per object. Before a pointer is first modified – save object pointer values locally. This can be done concurrently by a multithreaded program with no synchronization!

The write barrier (simplified) Update(Object **slot, Object *new){ Object *old = *slot if (!IsDirty(slot)) { log( slot, old ) SetDirty(slot) } *slot = new } Observation: If two threads: 1.invoke the write barrier in parallel, and 2.both log an old value, then both record the same old value.

The write barrier (simplified) Update(Object **slot, Object *new){ Object *old = *slot if (!IsDirty(slot)) { log( slot, old ) SetDirty(slot) } *slot = new } The “real” write barrier: In the object level With an optimistic initial “if”

Erez PetrankGC via Sliding Views14 Concurrent (intermediate) Algorithm: Stop all threads Scan roots (locals) Initiate write barrier usage Resume threads Trace from roots. Whenever a dirty objects is discovered use buffers to obtain its pointers. Stop write barrier usage Sweep to reclaim unmarked objects. Clear all buffers and dirty bits. Next goal: stop one thread at a time

Erez PetrankGC via Sliding Views15 The Sliding Views “Framework” Avoid simultaneous halting. Instead, stop one thread at a time. View of the heap is a “sliding view”. There is a time interval in which all objects are read. (But not one single point in time.)

Erez PetrankGC via Sliding Views16 Danger in Sliding Views Program does: P1  O P2  O P1  NULL Here sliding view reads P2 (NULL) Here sliding view reads P1 (NULL) Problem: reachability of O not noticed! Solution: “snooping”. If a pointer to O is stored while the sliding view is taken – do not reclaim O.

Erez PetrankGC via Sliding Views17 The Sliding Views Algorithm: Initiate snooping and write barrier usage For each thread: Stop thread and scan its roots (locals) Stop snooping Trace from roots and snooped objects. Whenever a dirty object is discovered use buffers to obtain its actual values. Stop write barrier usage Sweep to reclaim unmarked objects. Clear all buffers and dirty bits.

Erez PetrankGC via Sliding Views18 Optimizing the write barrier We only need to store: 1. non-null pointer values of object. 2. while tracing is on. 3. objects that have not been traced. 4. the object once. Slow path of the write barrier is seldom taken (~ 1/300) Implication of 3: new objects are never stored.

Erez PetrankGC via Sliding Views19 Write Barrier Statistics Long path frac.Benchmark 1 / 299SPECjbb / 894Compress 1 / 13,210Jess 1 / 305Db 1 / 160Javac 1 / 64,099Mpegaudio 1 / 16,572jack 1 / 4116mtrt2

Erez PetrankGC via Sliding Views20 Performance Measurements Implementation for Java on the Jikes Research JVM Compared collectors: Jikes parallel collector (Parallel) Jikes concurrent RC (Jikes concurrent) Benchmarks: Server benchmark: SPECjbb business-like transactions in a large firm Client benchmarks: SPECjvm mostly single-threaded client benchmarks

Erez PetrankGC via Sliding Views21 Pause Times vs. Parallel Jikes parallel

Erez PetrankGC via Sliding Views22 Pause Times vs. Jikes Concurrent

Erez PetrankGC via Sliding Views23 SPECjbb2000 Throughput Jikes parallel

Erez PetrankGC via Sliding Views24 SPECjvm98 Throughput Jikes parallel

Erez PetrankGC via Sliding Views25 SPECjbb2000 Throughput

Erez PetrankGC via Sliding Views26 SPECjvm98 Throughput

Erez PetrankGC via Sliding Views27 SPECjbb2000 Throughput

Erez PetrankGC via Sliding Views28 Most Related Collector Vast literature on on-the-fly mark & sweep collectors. The state-of-the-art collector is by Doligez-Leroy-Gonthier [POPL 93-94] Implemented for Java by IBM research: Domani-Kolodner-Petrank [PLDI 2000] Domani et al [ISMM 2000] Our new collector is the only alternative for tracing on-the-fly.

Erez PetrankGC via Sliding Views29 Comparison ? No available research implementation for Java. Parent o1o1 o2o2 p Some thoughts on locality: A difference in write barrier on pointer modification: [DLG]: Mark ex-referenced object [This work:] Copy (seldom) parent pointers, check (frequently) parent mark bits.

Erez PetrankGC via Sliding Views30 Related Work Snapshot tracing: Demers et al (1990), Furusou et al. (1991) On-the-fly tracing: Dijkstra et. al. (1976), Steele (1976), Lamport (1976), Kung & Song (1977), Gries (1977) Ben-Ari (1982,1984), Huelsbergen et. al. (1993,1998) Doligez-Gonthier-Leroy (1993-4), Domani- Kolodner-Petrank (2000) The RC sliding views algorithm: [Levanoni & Petrank: OOPSLA 01]. Generational extension of sliding views: Azatchi & Petrank [Compiler Construction 2003]

Erez PetrankGC via Sliding Views31 Conclusions A new non-intrusive, efficient mark & sweep garbage collector suitable for multiprocessors. An implementation on Jikes and measurements on a multiprocessor. Low pause times (1ms) small throughput penalty (10%).