Fm Schulte Lecture4

8/13/2019 Fm Schulte Lecture4

1/19

Lecture 4

Towards a Verifying Compiler:

Data Abstraction

Wolfram Schulte

Microsoft Research

Formal Methods 2006

Purity, Model fields, Inconsistency

_____________Joint work with Rustan Leino, Mike Barnett, Manuel Fhndrich, Herman Venter, RobDeLine, Wolfram Schulte (all MSR), and Peter Mller (ETH), Bart Jacobs (KULeuven) and Bor-Yuh Evan Chung (Berkley) .

Slides based on a presentation of Peter Mller given at MSR 5 2006


2/19

2

Review: Verification of OO Programs

with Invariants

What were the 2 major tricks to support invariants?

Which programs can we verify?

What are the limitations?


3/19

3

classRectangle implementsShape {intx1; y1; x2; y2;

voidDoubleWidth( )ensuresx2x1 == old( x2x1 ) * 2;{ } }

class

Rectangle: Shape {

intx1; y1; x2; y2;pure intWidth( )

private ensures result== x2x1; { }voidDoubleWidth( )ensuresWidth( ) == old( Width( ) ) * 2;{ }

}

Needed for

Subtyping

Information hiding

interfaceShape {voidDoubleWidth( )ensures ??;

}

Data Abstraction using Methods

interface

Shape {pure intWidth( );voidDoubleWidth( )ensuresWidth( ) == old( Width( ) ) * 2;

}


4/19


5/19

5

Problem 1: Inconsistent Specifications

Flawed specifications

potentially lead to

inconsistent axioms

How to guaranteeconsistency?

classInconsistent {pureintWrong( )

ensures result== 1;ensuresresult== 0;

{ }

}

class

List {

List next;

pureintLen( )ensuresresult== Len( ) + 1;

{ }

}


6/19

6

Problem 2: Weak Purity

Weak purity can be

observed through reference

equality

How to prevent tests for

reference equality?

classC {pureC Alloc( )ensuresfresh( result);

{ returnnewC( );}voidFoo( )

ensuresAlloc( )==Alloc( );{ ... }

}

Alloc( this,H) =Alloc( this,H)


7/19

7

Problem 3: Frame Properties

Result of pure methods

depends on the heap

How to relate invocations

that refer to differentheaps?

Has( list, o, H)

classList {pureboolHas( objecto ) { }voidRemove( objecto )

requiresHas( o );{ }

}

voidFoo( List list, objecto )requireslist.Has( o );

{log.Log( Message );

list.Remove( o );

}


8/19

8

classRectangle implementsShape {intx1; y1; x2; y2;

voidDoubleWidth( )ensuresx2x1 == old( x2x1 ) * 2;{ } }

classRectangle implementsShape {intx1; y1; x2; y2;modelintwidth | width == x2x1;voidDoubleWidth( )ensureswidth == old( width ) * 2;{ } }

Data Abstraction using Model Fields

Specification-only

fields

Value is determined

by a mapping from

concrete state

Similar to

parameterless pure

methods

interfaceShape {voidDoubleWidth( )ensures ??;

}

interfaceShape {model intwidth;voidDoubleWidth( )ensureswidth == old( width ) * 2;

}


9/19

9

Variant of Problem 3: Frame Properties

Assignment might

change model fields of

client objects

Analogous problem for

subtypes

How to synchronize

values of model fieldswith concrete fields?

classRectangle {modelintwidth | width == x2x1;voidDoubleWidth( )

modifiesx2, width;ensureswidth = old( width ) * 2;{ x2 := (x2 - x1) * 2 + x1; }

}

classLegend {Rectangle box; intfont;modelintmc | mc==box.width / font;}


10/19

10

classList {List next;invariantlist is acyclic;modelintlen | len == (next == null) ? 1 : next.len + 1; }

Validity Principle

Only model fields of valid objectshave to satisfy their

constraints

Avoids inconsistenciesdue to invalid objects

X, m: X.inv = valid Rm( X, X.m )


11/19

11

Decoupling Principle

Decoupling: Model fields are not updated instantlywhen

dependee fields are modified

Values of model fields are stored in the heap

Updated whenobject is being packed

classRectangle {modelintwidth | width == x2x1;voidDoubleWidth( ) requiresinv==valid; {

unpackthis;x2 := (x2x1) * 2 + x1;

packthis;}

: Rectangle

x1: 0

x2: 10

width: 10

: Rectangle

x1: 0

x2: 10

width: 10

: Rectangle

x1: 0

x2: 20

width: 10

: Rectangle

x1: 0

x2: 20

width: 20


12/19


13/19

13

The Methodology in Action

classLegend {repRectangle box;modelintmc |

mc == box.width / font;

}

classRectangle {voidDoubleWidth( )

requiresinv == valid &&owner.inv == mutable;

modifieswidth, x2;{

expose(this) {x2 := (x2x1) * 2 + x1;

}}

: Rectangle

x1: 0

x2: 10width: 10

: Legendmc: 2

: Rectangle

x1: 0

x2: 10width: 10

: Rectangle

x1: 0

x2: 20width: 10

: Rectangle

x1: 0

x2: 20width: 20

: Legendmc: 4


14/19

14

Automatic Updates of Model Fields

packX assertX nullX.inv = mutable;assertInv( X );assertp: p.owner = X p.inv = valid; X.inv := valid;

foreachm of X:assertr: Rm( X, r );X.m := chooser suchthatRm( X, r );end


15/19

15

Soundness

Theorem:

Proof sketch Object creation new:

new object is initially mutable

Field update X.f := E;

Model fields of X: asserts X.inv = mutable

Model fields of Xs owners: mutable dependent principle

unpackX:

changes X.inv to mutable

packX:

updates model fields of X

X,m: X.inv = valid Rm( X, X.m )


16/19


17/19

17

Problem 2 Revisited:

Restricted Weak Purity

pureC Alloc( ){ returnnewC( );}

Pure methods must notreturn references to new objects

(Compile time effect analysis)

Provide value types for sets, sequences, etc.


18/19

18

Problem 3 Revisited: Frame Properties

Model field solution does not

work for methods with

parameters

Caching of values not

possible for runtime

checking

Mutable dependent principle

too strict

classList {pureboolHas( objecto ){ }

voidRemove( objecto )requiresHas( o );

{ }

}

voidFoo( List list, objecto )requireslist.Has( o );

{

log.Log( Message );

list.Remove( o );

}


19/19

19

Summary

Data abstraction is crucial to express functional

correctness properties

Verification methodology for model fields

Supports subtyping

Is modular and sound

Key insight: model fields are reduced to ordinary fields with

automatic updates

Verification methodology for methods (not yet ready)

Partial solution: encoding, weak purity, consistency Future work: frame properties based on effects

Fm Schulte Lecture4

Documents

Transcript of Fm Schulte Lecture4