Verification of object-oriented programs with invariants Mike Barnett, Robert DeLine, Manuel Fahndrich, K. Rustan M. Leino, Wolfram Schulte Formal techniques for Java-like programs Darmstadt, Germany 21 July 2003 ¨

Example problem class T { int x, y; invariant x < y; public void m(U u) { x++; u.p(); y++; } invariant assumed to hold invariant may not hold invariant re-established problem if p calls back into T

Wanted: Methodology for invariants Ideal methodology: easy to understand statically and modularly checkable identifies all errors in a program permits all good programs

Invariant declarations – one per subclass class W extends V { int a; int[ ] b; invariant a b.length; … Object Y X W V U T class V extends U { P p; invariant p null; … Y y = new Y();

Special field inv keeps track of which invariants hold Object T U V W o.inv == o Object T U V W o.inv == U o Object T U V W o.inv == W == typeof(o) o Declarations and statements of programming language determine when inv is changed The associated invariants are checked when inv increases To prevent established invariants from having to be re-checked, one can treat fields in and below o.inv as read-only o is consistent

inv can be used in method specifications class T { int x, y; invariant x < y; public void m( ) requires inv == T; { int[ ] a = new int[y-x]; … } invariant holds here (checked at call sites) meaning: (t:T t.inv <: T t.x < t.y)

inv can be used in method specifications class T { int x, y; invariant x < y; public void m( ) requires inv == typeof(this); { int[ ] a = new int[y-x]; … } invariant holds here (checked at call sites) meaning: (t:T t.inv <: T t.x < t.y)

Exposed vs. owned Object T U V W o.inv == o Object T U V W o.inv == U o Object T U V W o.inv == W o consistent Object T U V W o.inv == W o exposedowned consistent Only consistent objects can be owned Special field exposed keeps track of exposed/owned exposed can be used in method specifications owned

p q U T Object Q P R 26 x V W Components

Component fields are declared as such Component fields are not necessarily unique references p q U T Object Components Object Q P R 26 x

When inv is increased to U, then U s components are checked to be consistent (p.inv == typeof(p)) and are subsequently un-exposed p q T Object Components Object Q P R 26 x U o.inv == Uo.inv == T owned

Decreasing inv below U exposes U s components p q T Object Components Object Q P R 26 x U o.inv == Uo.inv == T owned

Fields of components can be mentioned in invariants p q U T Object 26 x Q P R class U { … invariant x p.g p.g == p.h; invariant x q.k; h k g Fields of owned (un-exposed) objects are not allowed to be mutated

License to modify A field o.f can be modified only when o.exposed holds A method m is allowed a net effect on a field o.f (including o.inv and o.exposed) only if: – o.f appears in the modifies clause of m, or – o was not allocated on entry to m, or – o was not exposed on entry to m new

Method calls may change fields of un-exposed objects p U T Object 26 x P R class U { … invariant x p.g p.g == p.h; hg owned o

Related work rep types in CLU valid idiom in ESC/Modula-3 (implicit) pack/unpack operations in Vault and Fugue capability calculus ownership types invariant declarations in ESC/Java and JML locking and monitor disciplines in concurrent programming

Conclusions Simple! – inv, exposed, identification of components, protocol for changing inv/exposed – object references can always be copied but objects can have just one owner – fields can always be read but curbed expectations about the values read – frame problem solved without abstraction (e.g., data groups) Want: – experience, understanding of limits – extensions to support more good programs – more detailed comparison with other work exposed inv Object