Correctness-Preserving Derivation of Concurrent Garbage Collection Algorithms Martin T. Vechev Eran Yahav David F. Bacon University of Cambridge IBM T. J. Watson Research Center PLDI – June 2006
Why Concurrent Garbage Collection ? l Java and C# · Garbage-collected languages are prevalent l Multicore · Concurrency is becoming prevalent l Cheap RAM · Large heaps are becoming prevalent l Real-Time Systems · More widely used
Existing Way to Create a Concurrent GC REQUIREMENTS ENVIRONMENT Memory Model Thread Model Concurrency Primitives CPU primitives Throughput Memory Consumption Pause Time ? ? Implementation TECHNIQUES Tracing/reference counting moving Allocate White / Black Dijkstra / Steele / Yuasa Barrier Atomic / Incremental Stack Snapshot Write Barrier Atomic / Non-atomic Color toggle, stacklets etc etc • Hard to verify/test • Often buggy • Did the monkey choose well? ?
PROOFS ALGORITHMS FAMILY Concurrent GC algorithms and proofs are hard Dijkstra(C) ‘ 78 Yuasa ‘ 90 Steele(C) ‘ 75 Ben-Ari Base ‘ 84 Doligez(C) ‘ 93 Boehm ‘ 91 Ben-Ari Extended ‘ 84 Azatchi ‘ 03 Barabash ‘ 03 Domani ‘ 03 Pixley ‘ 88 Ben-Ari Base ‘ 84 THEOREM PROVING Doligez ‘ 94 Incorrect Correct (C) Corrected
Our Research Vision ENVIRONMENT (Declarative Specification) Memory Model Thread Model Concurrency Primitives CPU primitives REQUIREMENTS Throughput Memory Consumption Pause Time Automated System Formally Defined Techniques Optimal Correct Implementation
In This Work FIXED ENVIRONMENT REQUIREMENTS Memory Model Thread Model Concurrency Primitives CPU primitives Throughput Memory Consumption Automated System Pause Time Formally Defined Techniques for Tracing Non- Moving GC Algorithm 1 < Algorithm 2 < Algorithm 3 <… Algorithm N
Problem : Interference SYSTEM = MUTATOR || GC B C A 1. GC traced B Traced Not Traced
Problem : Interference SYSTEM = MUTATOR || GC B B C A 1. GC traced B C A 2. Mutator links C to B Traced Not Traced
Problem : Interference Traced Not Traced SYSTEM = MUTATOR || GC B B C A 1. GC traced B B C A 2. Mutator links C to B C A X 3. Mutator unlinks C from A
Problem : Interference Traced Not Traced SYSTEM = MUTATOR || GC C LOST B B C A 1. GC traced B B C A 2. Mutator links C to B B C A 3. Mutator unlinks C from A C A 4. GC traced A
The 3 Families of Concurrent GC Algorithms 1. Marks C when C is linked to B (DIJKSTRA) 3. Rescan B when 2. Marks C when C is linked to B link to C is removed (STEELE) (YUASA) B B C C A B A X C A • Solutions are applied uniformly for all objects
Contributions l Systematic Exploration · A new parametric model of concurrent GC · Better understanding · New algorithms – potentially useful l Formal Relationship between algorithms · Space - Relative precision between algorithms l Sharing Proof Burden · Correctness-preserving “transformations”
A Parametric Concurrent GC Skeleton l Intuition : Common out as much as possible l Record interaction history between collector and mutator during tracing l Collector exposes “hidden objects” based on entire interaction history
A Parametric Concurrent GC Skeleton Complete Garbage Collection COLLECTOR MUTATOR mark Change Heap Expose(L, D) … mark Change Heap Expose(L, D) reclaim
Dimensions: an intuition l The effect of each Mutator/GC action is controlled by a dimension A B C X Collector Scans Pointer Mutator Creates Pointer Mutator Overwrites Pointer Mutator Allocates Object Wavefront Granularity Counting Snapshot Allocation Color
Implementation Choice: Wavefront Per-Field Wavefront Per-Object Wavefront • Exact information • Approximate Information • One bit per field • More expensive • More synchronization • More garbage collected • One bit per object • Less expensive • Less synchronization • Less garbage collected
Choice: Record on Link or Unlink X Record on Link Record on Unlink • More synchronization • More garbage collected • Less synchronization • Less garbage collected
Per-Object WF A Per-Field WF Combined Choices A B X B A B X Record on Link Record on Unlink
Per-Field A Per-Obj A Per-Field B Per-Obj B Combined Choices Per Object A B X X X Rec. Link A Rec. Link B X X Rec. Link A Unlink B Rec. Unlink A Rec. Link B Rec. Unlink A Rec. Unlink B
Correctness • Transformations = Proof Steps APEX (U, U, {}) START WITH A CORRECT ALGORITHM RETAIN LESS GARBAGE STEELE DIJKSTRA (stacks, U, {}) STEELE-D STEELE-YC STEELE-D-YC DIJKSTRA-OLD DIJKSTRA-YC STEELE-BC HYBRID-YC (stacks, A, {}, {}) STEELE-D-BC DIJKSTRA-BC RETAIN MORE GARBAGE YUASA (stacks, A, {}, U)
Relative Precision l Intuition: an algorithm is more precise than another if it collects more garbage l An algorithm that is less precise (more conservative) than a correct algorithm is guaranteed to be correct l Should be a reference point for practical comparisons · no ad-hoc methods l Hard to do manually: need a tool to provide insights · Finding the “right” definition was harder than proving safety, yet simpler than “relative concurrency”
Precision APEX (U, U, {}) MORE PRECISE STEELE DIJKSTRA (stacks, U, {}) STEELE-D STEELE-YC STEELE-D-YC DIJKSTRA-OLD DIJKSTRA-YC STEELE-BC HYBRID-YC (stacks, A, {}, {}) STEELE-D-BC DIJKSTRA-BC YUASA (stacks, A, {}, U) LESS PRECISE
Conclusions l Systematic exploration of an algorithm space · Useful new algorithms l Formal definition of Relative precision between algorithms l A first step towards automatic derivation of concurrent garbage collectors
Скачать презентацию Correctness-Preserving Derivation of Concurrent Garbage Collection Algorithms Martin
8fe8a561a5ecd2fe6ba2d8dbab4e2f0d.ppt