Program Equivalence From Trace Equivalence Tim Wood 1 Sophia Drossopoulou 1 1 Imperial College London Wood, Drossopoulou (Imperial College London) Program Equivalence October 2014 1 / 30
Context Program maintenance is a common and important activity Programmers need to change or extend behaviour Intent is often to preserve most of the behaviour When changing one behaviour, easy and common to unintentionally damage some other behaviour Wood, Drossopoulou (Imperial College London) Program Equivalence October 2014 2 / 30
Context Program maintenance is a common and important activity Programmers need to change or extend behaviour Intent is often to preserve most of the behaviour When changing one behaviour, easy and common to unintentionally damage some other behaviour Programmers often don’t want to specify write tests for read or understand the whole program before they can change it Wood, Drossopoulou (Imperial College London) Program Equivalence October 2014 2 / 30
Question What does it mean “preserve most of the behaviour”? Can we automatically check that most of the behaviour is preserved? Wood, Drossopoulou (Imperial College London) Program Equivalence October 2014 3 / 30
Answer We propose a precise criterion to judge preservation of most of the behaviour Programmer tells us which objects should be affected by the modification If any other objects are affected, then the behaviour was not preserved Wood, Drossopoulou (Imperial College London) Program Equivalence October 2014 4 / 30
Answer We propose a sufficient condition for the criteria that is useful for our tool Condition depends only on the trace of method calls between the affected and unaffected objects Condition doesn’t require the unaffected objects to be precisely tracked We are developing a tool which uses symbolic execution and approximation (not described here) Wood, Drossopoulou (Imperial College London) Program Equivalence October 2014 5 / 30
Contributions Formal criterion for “preserve most of the behaviour” Useful sufficient condition for automated checking Automated proof of sufficiency of condition in Dafny Verifier Wood, Drossopoulou (Imperial College London) Program Equivalence October 2014 6 / 30
Example StudentDb db = new StudentDb (); 1 Logger logger = new Logger (); 2 Prizes prizes = new Prizes (); 3 void main () { 4 List <Student > students = db. orderedByGrade (); 5 logger.considered(students); 6 prizes.awardTo(students); } 7 8 9 class Prizes { void awardTo(List <Student > students) { 10 award(students.get (0)); 11 award(students.get (1)); 12 award(students.get (2));} 13 void award(final Student student) { /* ... */ }} 14 15 16 class Logger { void considered (List <Student > students) { 17 18 for (Student s : students) { 19 println(" considered : " + s.name ()); }}} 20 Wood, Drossopoulou (Imperial College London) Program Equivalence October 2014 7 / 30
Example StudentDb db = new StudentDb (); 1 Logger logger = new Logger (); 2 Prizes prizes = new Prizes (); 3 void main () { 4 List <Student > students = db. orderedByGrade (); 5 logger.considered(students); 6 prizes.awardTo(students); } 7 8 9 class Prizes { void awardTo(List <Student > students) { 10 award(students.get (0)); 11 award(students.get (1)); 12 award(students.get (2));} 13 void award(final Student student) { /* ... */ }} 14 15 16 class Logger { void considered (List <Student > students) { 17 sort(students , compareStudentsByName ()); 18 for (Student s : students) { 19 println(" considered : " + s.name ()); }}} 20 Wood, Drossopoulou (Imperial College London) Program Equivalence October 2014 8 / 30
Modified Objects ⊆ Allegedly Affected Example StudentDb db = new StudentDb (); 1 Logger logger = new Logger (); 2 Prizes prizes = new Prizes (); 3 void main () { 4 List <Student > students = db. orderedByGrade (); 5 logger.considered(students); 6 prizes.awardTo(students); } 7 8 9 class Prizes { Allegedly Affected void awardTo(List <Student > students) { 10 award(students.get (0)); 11 award(students.get (1)); 12 award(students.get (2));} 13 void award(final Student student) { /* ... */ }} 14 15 16 class Logger { void considered (List <Student > students) { 17 sort(students , compareStudentsByName ()); 18 for (Student s : students) { 19 println(" considered : " + s.name ()); }}} 20 Wood, Drossopoulou (Imperial College London) Program Equivalence October 2014 8 / 30
Example StudentDb db = new StudentDb (); 1 Logger logger = new Logger (); 2 Prizes prizes = new Prizes (); 3 void main () { 4 List <Student > students = db. orderedByGrade (); 5 logger.considered(students); 6 prizes.awardTo(students); } 7 8 9 class Prizes { Actually Affected void awardTo(List <Student > students) { 10 award(students.get (0)); 11 award(students.get (1)); 12 award(students.get (2));} 13 void award(final Student student) { /* ... */ }} 14 15 16 class Logger { void considered (List <Student > students) { 17 sort(students , compareStudentsByName ()); 18 for (Student s : students) { 19 println(" considered : " + s.name ()); }}} 20 Wood, Drossopoulou (Imperial College London) Program Equivalence October 2014 8 / 30
Equivalence Criteria Equivalence criteria are expressed only in terms of the objects involved in the behaviour of interest to the programmer Programmer can be ignorant of the rest of the objects and their behaviour Programmer doesn’t have to read or understand those parts, our criteria takes care that they are not affected Wood, Drossopoulou (Imperial College London) Program Equivalence October 2014 9 / 30
Equivalence Criteria Stack and Heap have the same shape when only the unaffected objects are considered. Wood, Drossopoulou (Imperial College London) Program Equivalence October 2014 10 / 30
State Equivalence - Example U A U A fi fi 3 0 3 2 4 2 this this o2 o2 l o o 2 9 o1 o1 f f o o 2 9 this 0 5 this 4 7 n n o o 1 8 4 3 v1 v2 Stack and heap at a point in execution of a different example program. Wood, Drossopoulou (Imperial College London) Program Equivalence October 2014 11 / 30
State Equivalence - Example U A U A fi fi 3 0 3 2 4 2 this this o2 o2 l o o 2 9 o1 o1 f f o o 2 9 this 0 5 this 4 7 n n o o 1 8 4 3 v1 v2 Unaffected objects and stack frames only Wood, Drossopoulou (Imperial College London) Program Equivalence October 2014 11 / 30
Sufficient Condition Objective: Avoid comparing the whole heap at each execution step Solution: Compare only methods calls/returns between affected and unaffected objects Also allows us to over-approximate some or all of the unaffected objects Wood, Drossopoulou (Imperial College London) Program Equivalence October 2014 12 / 30
Sufficient Condition - Illustration We want to establish that the unaffected objects correspond at each execution step . . . V1 . . . V2 Wood, Drossopoulou (Imperial College London) Program Equivalence October 2014 13 / 30
Sufficient Condition - Illustration Only need to consider states which are method calls or returns between affected and unaffected objects . . . V1 . . . V2 Wood, Drossopoulou (Imperial College London) Program Equivalence October 2014 13 / 30
Sufficient Condition - Illustration Only need to consider the topmost stack frame . . . V1 . . . V2 Wood, Drossopoulou (Imperial College London) Program Equivalence October 2014 13 / 30
Sufficient Condition - Illustration Intuition: the method calls and returns (and method parameters), between the affected and unaffected objects are enough information to uniquely deter- mine the unaffected objects V1 V2 Wood, Drossopoulou (Imperial College London) Program Equivalence October 2014 14 / 30
Trace Equivalence - Example t 1 (from v1) Method Params this: 3 Fifo return 3 this: 3 o: 1 add return this: 3 o: 2 add return remove this: 3 return 1 remove this: 3 return 2 Wood, Drossopoulou (Imperial College London) Program Equivalence October 2014 15 / 30
Trace Equivalence - Example t 1 (from v1) t 2 (from v2) Method Params Method Params this: 3 this:10 Fifo Fifo return 3 return 10 this: 3 o: 1 this:10 o: 8 add add return return this: 3 o: 2 this:10 o: 9 add add return return remove remove this: 3 this:10 return return 1 8 remove remove this: 3 this:10 return return 2 9 t 1 ∼ = t 2 using mapping (1,8),(3,10),(2,9) Wood, Drossopoulou (Imperial College London) Program Equivalence October 2014 15 / 30
Trace Equivalence - Example t 1 (from v1) t 3 (imaginary) Method Params Method Params Fifo this: 3 Fifo this: 7 return return 3 7 this: 3 o: 1 this: 7 o: 4 add add return return this: 3 o: 2 this: 7 o: 6 add add return return remove remove this: 3 this: 7 return 1 return 6 remove remove this: 3 this: 7 return return 2 4 t 2 �∼ = t 3 Wood, Drossopoulou (Imperial College London) Program Equivalence October 2014 15 / 30
Recommend
More recommend
