enhancing modular oo verification with separation logic
DESCRIPTION
Enhancing Modular OO Verification with Separation Logic. Wei-Ngan Chin 1,2 Cristina David 1 Huu Hai Nguyen 2 Shengchao Qin 3 1 National University of Singapore 2 Singapore-MIT Alliance 3 Durham University. Challenges of OO Verification. Must support behavioral subtyping . - PowerPoint PPT PresentationTRANSCRIPT
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>$