1 / 24

Correctness-Preserving Derivation of Concurrent Garbage Collection Algorithms

Correctness-Preserving Derivation of Concurrent Garbage Collection Algorithms. Martin T. Vechev. David F. Bacon. Eran Yahav. University of Cambridge. IBM T.J. Watson Research Center. PLDI – June 2006. Why Concurrent Garbage Collection ?. Java and C#

zanthe
Télécharger la présentation

Correctness-Preserving Derivation of Concurrent Garbage Collection Algorithms

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Correctness-Preserving Derivation of Concurrent Garbage Collection Algorithms Martin T. Vechev David F. Bacon Eran Yahav University of Cambridge IBM T.J. Watson Research Center PLDI – June 2006

  2. Why Concurrent Garbage Collection ? • Java and C# • Garbage-collected languages are prevalent • Multicore • Concurrency is becoming prevalent • Cheap RAM • Large heaps are becoming prevalent • Real-Time Systems • More widely used

  3. Existing Way to Create a Concurrent GC REQUIREMENTS ENVIRONMENT Throughput Memory Consumption Pause Time Memory Model Thread Model Concurrency Primitives CPU primitives 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 etc ?? • Hard to verify/test • Often buggy • Did the monkey • choose well?? Implementation

  4. Incorrect Correct (C) Corrected Concurrent GC algorithms and proofs are hard Yuasa ‘90 Steele(C) ‘75 Dijkstra(C) ‘78 FAMILY Ben-Ari Base ‘84 Doligez(C) ‘93 Boehm ‘91 Ben-Ari Extended ‘84 Azatchi ‘03 Barabash ‘03 ALGORITHMS Domani ‘03 Ben-Ari Base ‘84 Doligez ‘94 Pixley ‘88 PROOFS THEOREM PROVING

  5. Our Research Vision ENVIRONMENT (Declarative Specification) REQUIREMENTS Memory Model Thread Model Concurrency Primitives CPU primitives Throughput Memory Consumption Pause Time Automated System Formally Defined Techniques Optimal Correct Implementation

  6. In This Work FIXED ENVIRONMENT REQUIREMENTS Memory Model Thread Model Concurrency Primitives CPU primitives Throughput Pause Time Memory Consumption Automated System Formally Defined Techniques for Tracing Non- Moving GC Algorithm 1 Algorithm2 Algorithm3 AlgorithmN … < < <

  7. Traced Not Traced Problem : Interference SYSTEM = MUTATOR || GC B C A 1. GC traced B

  8. Traced Not Traced Problem : Interference SYSTEM = MUTATOR || GC B B C C A A 1. GC traced B 2. Mutator links C to B

  9. Traced Not Traced Problem : Interference SYSTEM = MUTATOR || GC B B B C C C X A A A 1. GC traced B 2. Mutator links C to B 3. Mutator unlinks C from A

  10. Traced Not Traced Problem : Interference SYSTEM = MUTATOR || GC C LOST B B B B C C C C A A A A 1. GC traced B 2. Mutator links C to B 3. Mutator unlinks C from A 4. GC traced A

  11. The 3 Families of Concurrent GC Algorithms 3. Rescan B when C is linked to B (STEELE) 1. Marks C when C is linked to B (DIJKSTRA) 2. Marks C when link to C is removed (YUASA) B B B B C C C C C X A A A • Solutions areapplied uniformly for all objects

  12. Contributions • Systematic Exploration • A new parametric model of concurrent GC • Better understanding • New algorithms – potentially useful • Formal Relationship between algorithms • Space - Relative precision between algorithms • Sharing Proof Burden • Correctness-preserving “transformations”

  13. A Parametric Concurrent GC Skeleton • Intuition : Common out as much as possible • Record interaction history between collector and mutator during tracing • Collector exposes “hidden objects” based on entire interaction history

  14. A Parametric Concurrent GC Skeleton Complete Garbage Collection COLLECTOR mark Expose(L,D) mark Expose(L,D) reclaim … MUTATOR Change Heap Change Heap

  15. C Dimensions: an intuition • The effect of each Mutator/GC action is controlled by a dimension A B X Collector Scans Pointer Wavefront Granularity Mutator Creates Pointer Counting Mutator Overwrites Pointer Snapshot Mutator Allocates Object Allocation Color

  16. Implementation Choice: Wavefront • Per-Field Wavefront • Exact information • One bit per field • More expensive • More synchronization • More garbage collected • Per-Object Wavefront • Approximate Information • One bit per object • Less expensive • Less synchronization • Less garbage collected

  17. Choice: Record on Link or Unlink X • Record on Link • More synchronization • More garbage collected • Record on Unlink • Less synchronization • Less garbage collected

  18. Combined Choices A B A B X Per-Object WF A B A B X Per-Field WF Record on Link Record on Unlink

  19. Combined Choices Per Object B A Per-Obj A Per-Obj B X X Per-Obj A Per-Field B X X X X Per-Field A Per-Obj B Per-Field A Per-Field B X X Rec. Link A Rec. Link B Rec. Link A Unlink B Rec. Unlink A Rec. Link B Rec. Unlink A Rec. Unlink B

  20. Correctness • Transformations = Proof Steps APEX (U, U, U, U, {}) START WITH A CORRECT ALGORITHM RETAIN LESS GARBAGE STEELE DIJKSTRA (stacks,U,{},U,{}) STEELE-YC STEELE-D STEELE-D-YC STEELE-BC DIJKSTRA-OLD DIJKSTRA-YC DIJKSTRA-BC HYBRID-YC (stacks,A,{},{},{}) STEELE-D-BC RETAIN MORE GARBAGE YUASA (stacks, A, {}, {}, U)

  21. Relative Precision • Intuition: an algorithm is more precise than another if it collects more garbage • An algorithm that is less precise (more conservative) than a correct algorithm is guaranteed to be correct • Should be a reference point for practical comparisons • no ad-hoc methods • Hard to do manually: need a tool to provide insights • Finding the “right” definition was harder than proving safety, yet simpler than “relative concurrency”

  22. Precision APEX (U, U, U, U, {}) MORE PRECISE STEELE DIJKSTRA (stacks,U,{},U,{}) STEELE-YC STEELE-D STEELE-D-YC STEELE-BC DIJKSTRA-OLD DIJKSTRA-YC DIJKSTRA-BC HYBRID-YC (stacks,A,{},{},{}) STEELE-D-BC LESS PRECISE YUASA (stacks, A, {}, {}, U)

  23. Systematic exploration of an algorithm space Useful new algorithms Formal definition of Relative precision between algorithms A first step towards automatic derivation of concurrent garbage collectors Conclusions

  24. The End

More Related