CGCExplorer: A Semi-Automated Search Procedure for Provably Correct Concurrent Collectors Martin Vechev Eran Yahav David Bacon University of CambridgeIBM T.J. Watson Research Center Noam Rinetzky Tel Aviv University

Synthesizing Concurrent Algorithms Designing practical and efficient concurrent algorithms is hard  trading off simplicity for performance  fine-grained coordination Result: sub-optimal, buggy algorithms Need a more structured approach to synthesize correct and optimal implementations out of coarse-grained specifications Some tasks are best done by machine, while others are best done by human insight; and a properly designed system will find the right balance. – D. Knuth

Synthesizing Concurrent Collectors Concurrent garbage collectors  Widely used  Must be correct, but also fast and scalable  Many algorithms, not many formal proofs A challenge problem for verification and synthesis Concurrency Heap with no a priori bound Focus on a specific family of collection algorithms  A generalization of Dijkstra’s algorithm  Concurrent, Tracing, Non-moving Single mutator, single collector (non-parallel)

Contributions Unifying framework – collection algorithms as common skeleton with parametric functions Trace Step Mutator Step Expose Mutator Collector

Contributions

specified various sets of blocks in 10 cycles explored 1,600,000 collection algorithms found 6 correct algorithms hundreds of variations Contributions

Overview High-level designFind a sufficient local invariant Find a sufficient abstraction Low-level searchVerify local invariant High-level designFind algorithm outline Find building blocks Low-level searchexplore algorithm space Generation Verification

Algorithm Space - Counting Algorithms Track collector’s progress (wavefront) Count pointer installations from behind wavefront  Increment on install, decrement on delete  Up to a predetermined counting threshold expose objects with count > 0 when finished tracing root scanned field object header 1 Collector wavefront

update source field to target obj check wavefront if source field behind wavefront - update new target object count - update old target object count read field value update wavefront (collector progress) mark target object select objects with count > 0 produce new roots Counting Algorithms: High Level View Trace Step Mutator Step Expose Mutator Collector

{ M1: old = source.field M2: w = source.field.WF M3: w  new.MC++ M4: w  log = log U {new} M5: w  old.MC-- M6: source.fld = new } { C1: dst = source.field C2: source.field.WF = true C3: mark dst } { E1: o = remove element from log E2: mc = o.MC E3: (mc > 0)  mark o E4: (mc > 0)  V = V U {o} return V } Trace Step (source, field)Mutator Step (source, field, new) Set Expose (log) Coarse-Grained to Fine-Grained Synchronization What now ? Can we remove atomics ? Result is incorrect, may lose objects! atomic

{ M1: old = source.field M2: w = source.field.WF M3: w  new.MC++ M4: w  log = log U {new} M5: w  old.MC-- M6: source.fld = new } { C1: dst = source.field C2: source.field.WF = true C3: mark dst } { E1: o = remove element from log E2: mc = o.MC E3: (mc > 0)  mark o E4: (mc > 0)  V = V U {o} return V } Trace Step (source, field)Mutator Step (source, field, new) Set Expose (log) What now ? Can we remove atomics ? Coarse-Grained to Fine-Grained Synchronization

{ C1: dst = source.field C2: source.field.WF = true C3: mark dst } { M1: old = source.field M2: w = source.field.WF M5: w  old.MC-- M3: w  new.MC++ M4: w  log = log U {new} M6: source.fld = new } { E1: o = remove element from log E2: mc = o.MC E3: (mc > 0)  mark o E4: (mc > 0)  V = V U {o} return V } Trace Step (source, field)Mutator Step (source, field, new) Set Expose (log) What now ? Can we remove atomics ? “When in doubt, use brute force.” --Ken Thompson “When in doubt, use brute force.” --Ken Thompson Coarse-Grained to Fine-Grained Synchronization

Tracing Step Building Blocks Mutator Building Blocks Expose Building Blocks M1: old = source.field M2: w = source.field.WF M3: w  new.MC++ M4: w  log = log U {new} M5: w  old.MC-- M6: source.fld = new C1: dst = source.field C3: mark dst C2: source.field.WF = true E1: o= remove element from log E2: mc = o.MC E3: (mc > 0)  mark o E4: (mc > 0)  V = V U {o} System Input – Building Blocks Input Constraints Mutator blocks: [M3, M4] Tracing blocks: [C1, C3] Expose blocks: [ E1, E2, E3, E4 ] Dataflow e.g. M2 < M3

System Output – (Verified) Algorithms Mutator Step (source, field, new) { M1: old = source.field M6: source.fld = new M2: w = source.field.WF M3: w  new.MC++ M4: w  log = log U {new} M5: w  old.MC— } Set Expose(log) { E1: o = remove element from log E2: mc = o.MC E3: (mc > 0)  mark o E4: (mc > 0)  V = V U {o} } Trace Step (source, field) { C1: dst = source.field C3: mark dst C2: source.field.WF = true } Explored 306 variations in around 2 mins Least atomic (verified) algorithm with given blocks

But What Now ? How do we get further improvement? Need more insights Need new building blocks  Example: start and end of collector reading a field Coordination Meta-data AtomicityOrdering

Continuing the Search… We derived a non-atomic algorithm (at the granularity of blocks)  Non atomic write-barrier, collector step and expose  System explored over 1,600,000 algorithms (took ~34 hours) All experiments took ~41 machine hours and ~3 human hours

CGC: Challenge for Automatic Verification Unbounded heap and sequence of mutations Checking a global invariant is hard  State space too big even for partial checking  3 nodes can quickly consume several GB in the SPIN model checker Solution Manually boil down to a local invariant Automatically prove local invariant  Use abstraction - unbounded number of concrete nodes conservatively represented by small, bounded number of abstract nodes

What Do We Prove? Want to prove collector safety  Retaining all live objects Local invariant: for every object  If an object is referenced from a scanned field at time of expose, it is either marked, or its count > 0 Show for any arbitrary object, under any arbitrary sequence of mutations

hiddn 2 root scanned field Abstraction Intuition Select tracked representative object Track reference count only for the selected object object header wavefront

hiddn 2 root Abstraction Intuition Only up to a fixed number of pointers matter – up to counting threshold Track these precisely Forget the rest scanned field object header wavefront

Recap High-level designFind a sufficient local invariant Find a sufficient abstraction Low-level searchVerify local invariant High-level designFind algorithm outline Find building blocks Low-level searchExplore algorithm space Generation Verification Find proof outline Find proof building blocks

What’s next? Concurrent Collector Synthesis  Get real algorithms  Mapping to real machine instructions Yet another level of search Synthesis of other concurrent algorithms  In the pipeline – concurrent set algorithms Local abstractions for concurrent programs

Invited Questions 1)Are your algorithms practical?Are your algorithms practical? 2)What are the limitations of this approach? Would it work for my problem?What are the limitations of this approach? Would it work for my problem? 3)How do you prove that your algorithms terminate?How do you prove that your algorithms terminate? 4)Can you show another algorithm?Can you show another algorithm? 5)How do you reduce the number of calls to the model- checker?How do you reduce the number of calls to the model- checker? 6)You didn’t mention any related workYou didn’t mention any related work 7)Can you give more details on experimental results?Can you give more details on experimental results?

ANSWERS FOLLOW

Where Do Building Blocks Come From? Read/write of heap location, and Collector coordination meta-data  e.g., collector progress, state flags

start_1 start_2 countmarked end_1 end_2 fld_1 fld_2 header fld_2start_3end_3 6 bits 5 bits … 1 bit 0 bits … start_1 start_2 countmarked end_1 end_2 fld_1 fld_2 header fld_2start_3 start_2 countmarked end_1 end_2 fld_1 fld_2 header fld_2start_3end_3 start_1 countmarked fld_1 fld_2 header fld_2 countmarked fld_1 fld_2 header fld_2end_3 countmarked fld_1 fld_2 header fld_2 Progress Coordination Metadata

Collector Building BlocksMutator Building Blocks Expose Building Blocks E1: o = remove element from log E2: mc = o.MC E3: (mc > 0)  mark o E4: (mc > 0)  V = V U {o} Refined Input – Finer Building Blocks M1: old = source.field M2s: ws = source.field.WFs M2e: we = source.field.WFe M3s: ws  new.MC++ M4s: ws  log = log U {new} M5e: we  old.MC-- M6: source.fld = new C1: dst = source.field C3: mark dst C2s: source.field.WFs = true C2e: source.field.WFe = true Input Constraints Mutator: [ M3s, M4s ] Tracing: [C1, C3], C2s < [C1, C3] < C2e Expose: [ E1, E2, E3, E4 ] Dataflow: e.g. M2s < M3s

Trace Step (source, field)Mutator Step (source, field, new) Set expose (log) { M1: old = source.field M2e: we = source.field.WFe M6: source.fld = new M2s: ws = source.field.WFs M3s: ws  new.MC++ M4s: ws  log = log U {new} M5e: we  old.MC– } { C2s: source.field.WFs = true C1: dst = source.field C3: mark dst C2e: source.field.WFe = true } { E1: o = remove element from log E2: mc = o.MC E3: (mc > 0)  mark o E4: (mc > 0)  V = V U {o} } System Output Constraints = Insights. e.g.: M2e < M6 < M2s C2s < C13 < C2e and.

(Some) Related Work Superoptimizer: a look at the smallest program, Massalin, ASPLOS’87  Finite state, limited length of instruction sequences Programming by Sketching, Solar-Lezama et. al., PLDI’05  Finite state Sketching with Stencils, Solar Leazma et. al., PLDI’07 Automatic discovery of mutual exclusion algorithms, Bar David and Taubenfeld, PODC’03  Finite state Correctness-Preserving Derivation of Concurrent Garbage Collection Algorithms, PLDI’06 CheckFence: Sebastian Burckhardt, Rajeev Alur and Milo M. K. Martin, PLDI’07 …

Algorithm Exploration less atomic more atomic different orders

Algorithm Exploration less atomic more atomic different orders less atomic more atomic different orders less atomic more atomic differe nt orders Trace StepMutator Step Expose

Limitations Need algorithm designer insights  Designer needs to understand results of each phase Abstraction is tailor-made  Designing an abstraction for the next collector? Pushing the limits of current model-checkers  Multiple mutators? Unbounded number of mutators?  Better partial-order reduction may help

Are Your Algorithms Practical? Are your algorithms correct? Honest answer: not yet  So far focused on correctness more than on performance  However, counting algorithms are of practical interest The moral is that for the design of multiprocessor installations we cannot rely on the traditional approach of the optimistic engineer, who, when the design looks reasonable, puts it together to see if it works. -- Edsger W.Dijkstra

Experimental Results RunTotalCheckedCorrectTime (min) Timed out TOTAL About 180 minutes of human working with the system (3.8 Ghz Xeon processor and 8 Gb memory running version 4 of RedHat Linux.)

Why Does it Work? Ingredients  Relentless optimism  Limited setting Limited Setting  single collector, single mutator  counting threshold is known  algorithm skeleton is fixed  algorithm uses a barrier before moving to the sweep phase  … (see paper)

Concurrent  Single mutator, single collector (not parallel) Tracing  Computes transitive reachability from roots Non-Moving  Collector does not relocate objects Algorithm Space - Counting Algorithms

How Do You Prove Termination? Manually

DEMONS START HERE IF NOT EARLIER

Synthesizing Concurrent Algorithms Some tasks are best done by machine, while others are best done by human insight; and a properly designed system will find the right balance. – D. Knuth it seems unavoidable that multiprocessor installations will be built… it seems equally unavoidable that many of them will be put together by aforementioned optimistic engineer. I shudder at the thought of all the new bugs: they will only delight the Devil. Am I too pessimistic? Nobody knows the trouble I have seen... --Edsger W.Dijkstra