1 / 24

Region-Based Model Abstraction

Region-Based Model Abstraction. Jeremy Condit Jim Larus Sriram Rajamani Jakob Rehof. OSQ Lunch 7 September 2003. Model Checking for C#. Want to check properties of a C# program e.g., conformance checking for web services The model checking approach:

korene
Download Presentation

Region-Based Model Abstraction

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. Region-BasedModel Abstraction Jeremy Condit Jim Larus Sriram Rajamani Jakob Rehof OSQ Lunch 7 September 2003

  2. Model Checking for C# • Want to check properties of a C# program • e.g., conformance checking for web services • The model checking approach: • Produce a simplified version of program with respect to the property • Check all possible executions of this model

  3. Our Abstraction Technique • We abstract a program by throwing away irrelevant code • Relevant data is identified by a third party • Programmer annotations • Program analysis • Counterexample-driven refinement • Relevant statements and expressions are those that deal with relevant data • Easy, right?

  4. Two Problems • Problem 1: Aliasing • Statements that affect aliasing can be relevant if (…) x = y; x.relevant_field = true; y.relevant_field = false; • Problem 2: Indirection • Relevant data can be buried within other nonsense x.y.z.relevant_field = true;

  5. Example class Transaction { … State s; … } class State { … relevant bool b; … }

  6. Example Transaction x; Transaction y; if (…) { Transaction t1 = new Transaction(); t1.s = new State(); t1.s.b = true; x = t1; } else { Transaction t2 = new Transaction(); t2.s = new State(); t2.s.b = false; x = t2; } if (…) { Transaction t3 = new Transaction(); t3.s = new State(); t3.s.b = true; y = t3; } else { Transaction t4 = new Transaction(); t4.s = new State(); t4.s.b = false; y = t4; } if (x.s.b) … if (y.s.b) … if (x.s.b) …

  7. Solution 1: Program slicing Transaction x; Transaction y; if (…) { Transaction t1 = new Transaction(); t1.s = new State(); t1.s.b = true; x = t1; } else { Transaction t2 = new Transaction(); t2.s = new State(); t2.s.b = false; x = t2; } if (…) { Transaction t3 = new Transaction(); t3.s = new State(); t3.s.b = true; y = t3; } else { Transaction t4 = new Transaction(); t4.s = new State(); t4.s.b = false; y = t4; } if (x.s.b) … if (y.s.b) … if (x.s.b) … Include all statements!

  8. Solution 2: Alias analysis Compute alias sets for x and y: Transaction x; Transaction y; if (…) { Transaction t1 = new Transaction(); t1.s = new State(); t1.s.b = true; x = t1; } else { Transaction t2 = new Transaction(); t2.s = new State(); t2.s.b = false; x = t2; } if (…) { Transaction t3 = new Transaction(); t3.s = new State(); t3.s.b = true; y = t3; } else { Transaction t4 = new Transaction(); t4.s = new State(); t4.s.b = false; y = t4; } if (x.s.b) … if (y.s.b) … if (x.s.b) … x = {t1, t2} y = {t3, t4} if (choose({t1,t2}).s.b) if (choose({t3,t4}).s.b) if (choose({t1,t2}).s.b)

  9. Region-Annotated Example class Transaction[] { … Statehi s; … } class State[] at  { … relevant bool b; … }

  10. Region-Annotated Example Transactionhr1ix; Transactionhr2iy; if (…) { Transactionhr1i t1 = new Transactionh1i(); t1.s = new Stateh1i(); t1.s.b = true; x = t1; } else { Transactionhr1i t2 = new Transactionh1i(); t2.s = new Stateh1i(); t2.s.b = false; x = t2; } if (…) { Transactionhr2i t3 = new Transactionh2i(); t3.s = new Stateh2i(); t3.s.b = true; y = t3; } else { Transactionhr2i t4 = new Transaction(); t4.s = new Stateh2i(); t4.s.b = false; y = t4; } if (x.s.b) … if (y.s.b) … if (x.s.b) …

  11. Solution 3: Regions Transactionhr1ix; Transactionhr2iy; if (…) { Transactionhr1i t1 = new Transactionh1i(); t1.s = new Stateh1i(); t1.s.b = true; x = t1; } else { Transactionhr1i t2 = new Transactionh1i(); t2.s = new Stateh1i(); t2.s.b = false; x = t2; } if (…) { Transactionhr2i t3 = new Transactionh2i(); t3.s = new Stateh2i(); t3.s.b = true; y = t3; } else { Transactionhr2i t4 = new Transaction(); t4.s = new Stateh2i(); t4.s.b = false; y = t4; } if (x.s.b) … if (y.s.b) … if (x.s.b) … if (…) { s = new State(); s.b = true; r1[= s; } else { s = new State(); s.b = false; r1[= s; } if (…) { s = new State(); s.b = true; r2[= s; } else { s = new State(); s.b = false; r2[= s; } if (choose(r1).b) … if (choose(r2).b) … if (choose(r1).b) …

  12. Why Regions? • Two phase alias analysis • Static: Identify scope of alias sets • Dynamic: Populate alias sets with objects • Beneficial for model checker • Avoid loss of precision when generating models • Produce more precise alias information by exploiting the power of the model checker • Solves aliasing and indirection problems • Allows fine-grained tuning of trade-off between precision and performance

  13. Our Abstraction • Based on RegJava • Region type system for a Java-like language • Includes proof of soundness • Given a statement or expression p, we define «p¬ to be its abstraction • Distinguish three cases: 1. Relevant data 2. References to relevant data 3. All others

  14. Example: Expressions Example:

  15. Example: Statements Example:

  16. Soundness Theorem • Theorem: For any execution of the original RegJava program, there is a corresponding execution of the model • Proof Sketch: Since we replace occurrences of variables and fields with a choice over the corresponding region, any possible value in the original program will be considered by the model

  17. Context-Sensitivity • Region type systems make our approach context-sensitive void foo[1, 2](Stateh1i s1, Stateh2i s2) { s1.b = true; if (s2.b) … } void foo_model(Set 1, Set2) { choose(1).b = true; if (choose(2).b) … }

  18. Context-Sensitivity, Part 2 • But we still have problems now and then: void foo[](Statehi s1, Statehi s2) { Statehi tmp; if (…) { tmp = s1; } else { tmp = s2; } tmp.b = true; } void foo_model(Set ) { choose().b = true; }

  19. Context-Sensitivity, Part 3 • We can create an even more dynamic model void foo[1, 2](Stateh1i s1, Stateh2i s2) { Statehi tmp; if (…) { tmp = s1; } else { tmp = s2; } tmp.b = true; } void foo_model(Set 1, Set 2) { Set ; if (…) {  [= 1; } else {  [= 2; } choose().b = true; }

  20. Capturing Correlations • Need to represent important correlations in the model • Solution: Introduce local variables Statehi s = …; s.b = true; s.f = 42; Source: choose().b = true; choose().f = 42; Statehi s = choose(); s.b = true; s.f = 42; Model:

  21. Implementation • Based on Dave Hanson and Todd Proebsting’s research C# compiler • Five stages: • Introduce region variables • Gather constraints and solve • Determine live regions at each AST node • Insert letregion statements to limit region scope • Translate to Zing

  22. The Fine Print • RegJava’s regions use a stack discipline • Letregion statements tend to accumulate near the most general scopes in the program • We’re looking at less restrictive region systems • Region parameters accumulate upward in the class hierarchy • Interfaces can’t be modeled properly • We’re looking at alternative approaches to object-oriented region systems

  23. Related Work • Other model checking projects • SLAM, BLAST, Bandera • Regions in Cyclone • Flow-sensitive Cqual

  24. Conclusion • Region type systems solves several model generation problems: • Aliasing • Indirection • Efficient division of labor: • Model generation phase (static) • Model checking phase (dynamic) • Other compiler analyses may benefit from this approach!

More Related