POPL 2008

Enhancing Modular OO Verification with Separation

LogicWei-Ngan Chin1,2 Cristina

David1

Huu Hai Nguyen2 Shengchao Qin3

1 National University of Singapore2 Singapore-MIT Alliance3 Durham University

Tokyo 2008 2

Challenges of OO Verification

Must support behavioral subtyping.Must support class inheritance.Must support casting.Good to support class invariants.Good to support super/direct calls.

• precision • efficiency (minimize code re-verification)

Tokyo 2008 3

Separation Logic and Abstraction [Parkinson&Bierman, POPL’05]

• Introduces abstract predicate family– allows a definition for each class type– very powerful idea

• Re-verification when method inherited• Cannot handle super calls• Specs may be imprecise

Tokyo 2008 4

Separation Logic

• Foundations:– O’Hearn and Pym, “The Logic of Bunched Implications”, Bulletin of Symbolic Logic 1999– Reynolds, “Separation Logic: A Logic for Shared Mutable Data Structures”, LICS 2002

• Extension to Hoare logic to reason about shared mutable data structures

p1 * p2: the heap can be split into two disjoint

parts (p1 holds for one part and p2 holds for the other)

Tokyo 2008 5

Outline

• Introduction• Our Approach

– Enhanced Spec Subsumption– Static & Dynamic Specs– Key Principles– Object Representation– Class Invariants– Avoiding Re-verification– Deriving Specs

• Experimental Results• Conclusion

Tokyo 2008 6

Behavioral Subtyping

• Liskov's Substitutivity Principle (1988) :

– an object of a subclass can always be passed to a location where an object of its superclass is expected– enforce behavioral subtyping with a subsumption relation

Tokyo 2008 7

Specification Subsumption Relation

class A {

t mn(..) where preA *! postA {...}

} class B extends A {

t mn(..) where preB *! postB {...}

}Spec (preB *! postB) is a subtype of (preA *! postA) if:

(preB *! postB) <:B (preA *! postA)

contravariance covariance

) preB postB ) postApreA old(preA)Æ

Leavens&Naumann(‘06)

Tokyo 2008 8

Spec (preB *! postB) is a subtype of (preA *! postA) if:

) preB postB

(preB*!postB) <:B (preA*!postA)

Enhanced Specification Subsumption

* ) postA *

• With the help of frame rule `{P} c {Q}

`{P * } c {Q * }

preAÆtype(this)<:B

Castagna(TOPLAS‘95)

Tokyo 2008 9

Outline

• Introduction• Our Approach

– Enhanced Spec Subsumption– Static & Dynamic Specs– Key Principles– Object Representation– Class Invariants– Avoiding Re-verification– Deriving Specs

• Experimental Results• Conclusion

Tokyo 2008 10

Static and Dynamic Spec

A static spec: • describes just a single method• used for statically-dispatched calls (e.g. super/direct)• can be very precise

A dynamic spec: • describes a method and its overriding methods• used for dynamically-dispatched calls• less precise

Tokyo 2008 11

Static and Dynamic Specs : Exampleclass Cnt { int val; Cnt(int v) {this.val:=v} void tick() {this.val:=this.val+1} int get() {this.val} void set(int x) {this.val:=x} }

class FastCnt extends Cnt { FastCnt(int v) {this.val:=v} void tick() {this.val:=this.val+2} }

class PosCnt extends Cnt inv this.val¸0 { PosCnt(int v) {this.val:=v} void set(int x) {if x¸0 then this.val:=x else error()} }

static this::Cnt<n>$ *!

this::Cnt<n+1>$dynamic this::Cnt<n>$

*! this::Cnt<b>$

Tokyo 2008 12

Static and Dynamic Specs : Exampleclass Cnt { int val; Cnt(int v) {this.val:=v} void tick() {this.val:=this.val+1} int get() {this.val} void set(int x) {this.val:=x} }

class FastCnt extends Cnt { FastCnt(int v) {this.val:=v} void tick() {this.val:=this.val+2} }

class PosCnt extends Cnt inv this.val¸0 { PosCnt(int v) {this.val:=v} void set(int x) {if x¸0 then this.val:=x else error()} }

static this::Cnt<n>$ *!

this::Cnt<n+1>$dynamic this::Cnt<n>$

*! this::Cnt<b>$

PosCnt has inv this.val¸0 ) strengthen the precond

Æ n¸0Æ n+1·b·n+2

Cnt.tick is overridden ) weaken the postcond

Æ n+1·b·n+2Æ b=n+1

Tokyo 2008 13

Outline

• Introduction• Our Approach

– Enhanced Spec Subsumption– Static & Dynamic Specs– Key Principles– Object Representation– Class Invariants– Avoiding Re-verification– Deriving Specs

• Experimental Results• Conclusion

Tokyo 2008 14

Key Principles

• Static spec must be given for each new method.• Code verification is done only for static spec.• Dynamic spec is either given or derived.• Subsumption relations:

Static-Spec(A.mn) Dyn-Spec(A.mn)<:

min. re-verification

class A {// defines mn }

Tokyo 2008 15

Key Principles

• Static spec must be given for each new method.• Code verification is done only for static spec.• Dynamic spec is either given or derived.• Subsumption relations:

Static-Spec(A.mn) Dyn-Spec(A.mn)<:

min. re-verification

class A {// defines mn }class B extends A {// overrides mn}

Dyn-Spec(B.mn)

<:

ensures behavioral subtyping

Tokyo 2008 16

Key Principles

• Static spec must be given for each new method.• Code verification is done only for static spec.• Dynamic spec is either given or derived.• Subsumption relations:

Static-Spec(A.mn) Dyn-Spec(A.mn)<:

min. re-verification

class A {// defines mn }class B extends A {// overrides mn}class C extends A {// inherits mn}

Dyn-Spec(B.mn)

<:

ensures behavioral subtyping

Static-Spec(C.mn)

min. re-verification

<:

Tokyo 2008 17

Outline

• Introduction• Our Approach

– Enhanced Spec Subsumption– Static & Dynamic Specs– Key Principles – Object Representation– Class Invariants– Avoiding Re-verification– Deriving Specs

• Experimental Results• Conclusion

Tokyo 2008 18

Object Representation

class A { // fields v1..n

....}

class B extends A { // fields w1..m ....}

y::B<t,v1..n,w1..m,p>

y::A<t,v1..n,q>*q::Ext<B,w1..m,p>

upcast downcast

fields

fields of A fields of B

extension record for the extra fields of B

actual typeextension

Tokyo 2008 19

Object Representation

class A { // fields v1..n

....}

class B extends A { // fields w1..m ....}

y::B<t,v1..n,w1..m,p>

y::A<t,v1..n,q>*q::Ext<B,w1..m,p>

upcast downcast

LOSSLESS CASTING

Tokyo 2008 20

Partial and Full Views

Other fields w1..m of subclass t of c

x Fields v1..n of c-class

Seen as a c-class obj (actual type t)

Partial view: - x::c<t,v1..n,p> - no extension records - shorthand x::c<v1..n>

Full view:- x::c<t,v1..n,p> * p::ExtAll<c,t>- ExtAll<c,t> captures all the extensions of subclass t of c- shorthand x::c<v1..n>$

- Static specs- Improves precision

- Dynamic specs

Tokyo 2008 21

Outline

• Introduction• Our Approach

– Enhanced Spec Subsumption– Static & Dynamic Specs– Key Principles – Object Representation– Class Invariants– Avoiding Re-verification– Deriving Specs

• Experimental Results• Conclusion

Tokyo 2008 22

Ensuring Class Invariants

class PosCnt extends Cnt inv this.val¸0 {...}

Invariant-enhanced predicate:

root::PosCnt#I<t,v,p> == root::PosCnt<t,v,p> * v¸0

Q: How and when to check for class inv?

Tokyo 2008 23

Invariant-Enhanced Predicate : Example

class PosCnt extends Cnt inv this.val¸0 { ... void set(int x) static this::PosCnt<v> Æ x¸0 *! this::PosCnt#I<x>

void tick() static this::PosCnt#I<v> *! this::PosCnt#I<v+1> ...}

inv is temporarily

broken

Tokyo 2008 24

Invariant-Enhanced Predicate : Example

class PosCnt extends Cnt inv this.val¸0 { ... void set(int x) static this::PosCnt<v> Æ x¸0 *! this::PosCnt#I<x>

void tick() static this::PosCnt#I<v> *! this::PosCnt#I<v+1> ...}

inv is temporarily

broken

• inv enforced at each call site • assumed at the beginning of method decl

Tokyo 2008 25

Invariant-Enhanced Predicate : Example

class PosCnt extends Cnt inv this.val¸0 { ... void set(int x) static this::PosCnt<v> Æ x¸0 *! this::PosCnt#I<x>

void tick() static this::PosCnt#I<v> *! this::PosCnt#I<v+1> ...}

inv is temporarily

broken

• inv enforced at each call site • assumed at the beginning of method decl

• inv enforced at the end of the method decl • assumed after each call site

Tokyo 2008 26

Outline

• Introduction• Our Approach

– Enhanced Spec Subsumption– Static & Dynamic Specs– Key Principles – Object Representation– Class Invariants– Avoiding Re-verification– Deriving Specs

• Experimental Results• Conclusion

Tokyo 2008 27

Re-verification of Inherited Methods

class A {// fields v*

...t mn(…) static spA { ..body .. }

}

class B extends A {// fields w*..t mn(…) static spB// method mn is inherited}

Is there a need tore-verify spB against body of mn?

Tokyo 2008 28

Statically-Inherited Method: Intuition

Will a call this.mn(...) modify w*?

B.mn is statically inherited

NO

NOT statically inherited

YES

Other fields w1..m of subclass t of c

this Fields v1..n of c-class

Seen as a c-class obj (actual type t)

Tokyo 2008 29

Statically-Inherited Method: Definition

class A {// fields v*

...t mn(…) static spA { ... this.mn2(); ... } }

class B extends A {// fields w*

..t mn(…) static spB// method mn is inherited}

A.mn is statically-inherited into B if:• it is not overridden in B

Tokyo 2008 30

Statically-Inherited Method: Definition

class A {// fields v*

// defines mn2...t mn(…) static spA { ... this.mn2(); ... } }

class B extends A {// fields w*// inherits mn2..t mn(…) static spB// method mn is inherited}

A.mn is statically-inherited into B if:• it is not overridden in B • for all the calls this.mn2(..) with mnmn2, B.mn2 is statically-inherited from A.mn2

Tokyo 2008 31

Re-verification of Inherited Methods

Q: Verify spB against the body of A.mn?

spB inherited?

B.mn statically inherited or full

views used?

NO VERIFICATION spA<:spBverify spB

against the body of A.mn

YES

YES

NO

NO

Tokyo 2008 32

Outline

• Introduction• Our Approach

– Enhanced Spec Subsumption– Static & Dynamic Specs– Key Principles – Object Representation– Class Invariants– Avoiding Re-verification– Deriving Specs

• Experimental Results• Conclusion

Tokyo 2008 34

Deriving Specs (2)

• Specification Specialization – strengthen dynamic spec of overriding

method with the dynamic spec of overridden method

– intersection type• Specification Abstraction

– weaken dynamic spec of overridden method with dynamic spec of the overriding method

– union type

Tokyo 2008 35

Outline

• Introduction• Our Approach

– Enhanced Spec Subsumption– Static & Dynamic Specs– Key Principles – Object Representation– Class Invariants– Avoiding Re-verification– Deriving Specs

• Experimental Results• Conclusion

Tokyo 2008 36

Initial Experiment

• Code Verification > Spec Subsumption Checking

Tokyo 2008 37

Conclusion• Must support:

– behavioral subtyping, class inheritance, casting • Good to support:

– class invariants, super/direct calls• Danger:

– lose precision, efficiency

• Advocate co-existence of static and dynamic specs • Key principles:

– use static spec where possible ) precision– keep code re-verifications to a minimum ) efficiency

• Slight emphasis on static specs:

– can derive dynamic specs

Tokyo 2008 38

Thank you!Questions?

Tokyo 2008 39

Spec Subsumption Checking

Static_spec(Cnt.set) <: Dyn_spec(Cnt.set)this::Cnt<t,v,p>*->this::Cnt<t,x,p> <:this::Cnt<t,v,q>*q::ExtAll<Cnt,t> /\ x>=0 *->this::Cnt<t,x,q>*q::ExtAll<Cnt,t>Contravariance on precond:this::Cnt<t,v,q>*q::ExtAll<Cnt,t> /\ x>=0 |-this::Cnt<t,v,p>* = p::ExtAll<Cnt,t> /\ x>=0Covariance on postcond:this::Cnt<t,x,p>* |- this::Cnt<t,x,q>*q::ExtAll<Cnt,t>

Tokyo 2008 40

Spec Subsumption Checking

Dyn_spec(PosCnt.set) <: Dyn_spec(Cnt.set)this::PosCnt<v>$ *! this::PosCnt#I<x>$ <:

this::Cnt<v>$ /\ x>=0 /\ (type(this)<:PosCnt)

*! this::Cnt<x>$

Contravariance on precond:this::Cnt<v>$ /\ x>=0 /\ (type(this)<:PosCnt)|-this::PosCnt<v>$ * = x>=0Covariance on postcond:this::PosCnt#I<x>$ * |- this::Cnt<t,x,q>$