1. Object Invariants in Dynamic Contexts K.R.M. Leino and P. Muller 15-819: Objects and Aspects Presented by Jonathan Aldrich

2. Outline Problem –Modular enforcement of invariants –Separate reasoning with callbacks and inheritance Solution –Class invariants –Partial packing and unpacking –“Ownership” relation Discussion

3. Callbacks and Invariants class T { int a, b ; invariant 0 <= a < b public T( ) { a := 0 ; b := 3 ; } public void m(...) { int k := 100/(b - a) ; a := a +3 ; P(...) ; b := (k + 4). b ; } What if P calls m? –Soundness: Must ensure it doesn’t, or that the invariant is not assumed by m

4. Inheritance and Invariants class Derived extends Base { int a, b ; invariant 0 <= a < b public void m(...) { int k := 100/(b - a) ; super.m(...) ; a := a +3 ; P(...) ; b := (k + 4). b ; } What about the invariants of Base? –Modularity: would like to assume that super call ensures them –Need notion entering and leaving a class scope

5. Class Invariants class C extends B { int w ; invariant w < 100 ;... } class B extends A { int z ; invariant y < z ;... } class A extends object { int x, y ; invariant x < y ;... } inv = A –Invariant A must hold –B and C may or may not hold C:w = 43 B:z = 6 A:x = 5 y = 7 object: inv = A

6. Class Invariants class C extends B { int w ; invariant w < 100 ;... } class B extends A { int z ; invariant y < z ;... } class A extends object { int x, y ; invariant x < y ;... } o.z = y+1; pack o as B; pack o as C; continue… C:w = 43 B:z = 6 A:x = 5 y = 7 object: inv = A

7. Class Invariants class C extends B { int w ; invariant w < 100 ;... } class B extends A { int z ; invariant y < z ;... } class A extends object { int x, y ; invariant x < y ;... } o.z = y+1; pack o as B; pack o as C; continue… C:w = 43 B:z = 8 A:x = 5 y = 7 object: inv = A

8. Class Invariants class C extends B { int w ; invariant w < 100 ;... } class B extends A { int z ; invariant y < z ;... } class A extends object { int x, y ; invariant x < y ;... } o.z = y+1; pack o as B; pack o as C; continue… C:w = 43 B:z = 8 A:x = 5 y = 7 object: inv = B

9. Class Invariants class C extends B { int w ; invariant w < 100 ;... } class B extends A { int z ; invariant y < z ;... } class A extends object { int x, y ; invariant x < y ;... } o.z = y+1; pack o as B; pack o as C; continue… C:w = 43 B:z = 8 A:x = 5 y = 7 object: inv = C

10. Inheritance and Invariants class Derived extends Base { int a, b ; invariant 0 <= a < b public void m(...) { unpack this from Derived int k := 100/(b - a) ; super.m(...) ; // unpacks and re-packs Base a := a +3 ; P(...) ; b := (k + 4). b ; pack this as Derived } Incremental unpacking and re-packing supports modular verification

11. Callbacks and Invariants class T { int a, b ; invariant 0 <= a < b public T( ) { a := 0 ; b := 3 ; } public void m(...) requires this. inv = T { unpack this from T ; int k := 100/(b - a) ; a := a +3 ; P(...) ; b := (k + 4). b ; pack this as T ; } What if P calls m? –It must first restore the invariant and pack this as T, because m’s precondition assumes that T is packed

12. Invariants and Sub-objects class BTree { int i ; BTree left, right ; invariant (left != null)  left.i < i  (right != null)  right.i ≥ i ; } How to ensure invariant modularly? –What if someone modifies left.i without going through the current object?

13. Ownership, Boogie Style p is owned by o at T –p.owner = [o,T] p is committed –p.committed All invariants hold for committed objects –p.committed  p.inv = type(p) Object is committed when owner is packed –p.owner = [o,T]  (p.committed  o.inv ≤ T)

14. Invariants and Sub-objects class BTree { int i ; rep BTree left, right ; invariant left.owner = [this, BTree] ; invariant right.owner = [this, BTree] ; invariant (left != null)  left.i < i  (right != null)  right.i ≥ i ; } Invariant can rely on owned objects –unpack this, invariants hold for children –children can’t be unpacked (and thus can’t have broken invariants) unless owner is first unpacked

15. Ownership Transfer transferable class Possession {...} class Person { rep Possession possn ; void donateTo(Person p) requires ¬committed È inv = Person ; requires possn = nullÈ Ètype(possn) = Possession ; requires p = null È p = this È ¬p.committed È p.inv = Person ; modifies possn, p.possn ; { unpack this from Person ; unpack p from Person ; unpack possn from Possession ; transfer possn to [p, Person] ; pack possn as Possession ; p.possn := possn ; pack p as Person ; possn := null ; pack this as Person ; }... }

16. Is “ownership” really Ownership? Ownership in Boogie –Allows external aliases (but can’t mutate through them) –Supports ownership transfer –Heavyweight: must track precisely Classical Ownership –External aliases –No ownership transfer –Lightweight: can track with types I find this all a bit misleading… probably better to use a different term

17. explain visibility rules field update rules

18. Discussion Practicality –Requires very careful tracking of containing object state –Forbids iterators, etc. –Strong conditions for transfer Lessons for informal reasoning? Applicability to aspects?