Using data groups to specify and check side effects

1
Using data groups to specify and check side
effects

• K. Rustan M. Leino
• Microsoft Research
• Arnd Poetzsch-Heffter
• Universität Kaiserslautern
• Yunhong Zhou
• HP SRC
• Work done at Compaq SRC

18 June 2002PLDI02, Berlin, Germany
2
Introduction

• The Problem
• Checking effects in a modular and extensible
  way.
• Motivation
• Optimizations
• Error detection
• Aliasing Restrictions
• Pivot uniqueness
• Owner exclusion

3
Modifies clause
method p(x, y) modifies M
Grants the implementations of pthe license to
modify M
Challenge Soundness - Does p(x,y) modify only
M?
4
Context
Staticprogramchecker
Pieces of a
Warningmessages
Program
Modular checking
5

• Modular checking
• Access to complete program not necessary
• Dont assume availability of
• implementations of called methods
• all of the programs variables
• Modular soundness
• Only interface properties of checked parts are
  needed to check extensions
• Checking is sound for any extension of the
  program

6
Extension of the code
class Position int x, y virtual void
update() modifies x,y ...
class Position3D Position int z void
update() modifies(x,y,z) ...
7
Information hiding
Queue
q
head
17
method Enqueue(x) modifies ???
Buffer
size
8
capacity
public
32
buf
method Enlarge() modifies capacity,
private
8
Data groups
Queue
q
group contents
head
17
method Enqueue(x) modifies contents
method Enqueue(x) modifies ???
Buffer
size
8
capacity
public
32
buf
method Enlarge() modifies capacity,
private
9
Source code
class Queue public group contents public
void Enqueue(object x) modifies contents
Note direction of declarations
head ? contents size ? contents
private int head in contents private int size
in contents
private Buffer buf maps capacity into contents
buf.capacity ? contents
10
Data Groups

• A set of variables and nested data groups
• Membership defined incrementally
• A field/group can be part of multiple groups
• The license to modify a group implies the license
  to modify the members of the group

group contents
head size
buf.elements
capacity
array
11
Extension of the code - solution
class Position GROUP G int x in G, y in
G virtual void update() modifies G ...
class Position3D Position int z in G
void update() ...
new field added to G
same modifies clause
12
Inclusion types
Local Inclusion
head ? contents size ? contents
private int head in contentsprivate int size in
contents
pivot field
Queue
private Buffer buf maps capacity into contents
buf
buf.capacity ? contents
Buffer
capacity
13
Summary so far

• modular checking
• modifies clauses
• information hiding
• data groups!
• Extensibility
• What about soundness?
• next 2 problems and proposed solutions

14
Problem 1
group contents
Queue
method Enqueue(x) modifies contents
Client
head
Queue q new Queue()
method Buffer m() modifies
Buffer b q.m()
size
int c b.capacity
buf
q.Enqueue(5)
assert c b.capacity
q
Buffer
capacity
method Buffer m() return buf Buffer buf
maps capacity into contents
b
15
Solution 1 Pivot uniqueness restriction

• Make pivot fields unique

Queue
Buffer
capacity
group contents
buf
field buf maps capacity into contents

• Three restrictions
• Pivot fields can only be assigned new or null
• Cant assign a pivot field to anything. This
  avoid the previous problem
• What about function parameters?

16
Pivot uniqueness - cont
method Enqueue ( object x ) if ( size
buf.capacity ) buf.Enlarge ()

• permit aliasing with parameters, but do not allow
  assigning to/from formal parameters

• results
• Pivot fields are either null or unique (Except
  for formal parameter aliases on the call stack).
• Static checker will not complain the assertion in
  the client regardless of whether declaration of
  buf is available to it.

17
Problem 2
new Queue()
Queue q
Queue
q.m()
Buffer b
method p( , )
modifies contents
group contents
head
size
buf

q
class Queue p(this, this.buf) Buffer
buf maps capacity into contents
Buffer
capacity
b
18
Problem 2 analysis

• Can happen only when all three apply
• The pivot field is passed as a parameter
  (otherwise pivot uniqueness prevents it)
• The owner of the pivot value (q in the example)
  is accessible to the callee.
• q.contents is modified.

19
Solution 2 Owner exclusion restriction
For any pivot field field buf maps capacity
into contents and method method m(, T x,
) modifies , E.contents, add to m the
following precondition E.buf ! x
20
Whats in the paper

• Sound formalization
• a core object-oriented language (oolong )
• pivot uniqueness and owner exclusion restrictions
• translation from oolong to verification conditions

21
The Semantic Model

• Object store S (q.buf) b
• Define transitive inclusion relation
• _ in _ Attrib x Group bool
• _ maps _ into _ Field x Attrib x Group
  bool

capacity
group contents
buf
q
b
X Y /\ F in G
S(q.buf).capacity q.Contents
22
Semantic Model - Field update

• Field update commands require that their targets
  be assignable according to the modifies list w
  evaluated in the store S.

Mod(X.A, w, S) ? alive(S,X) V incl (X.A, w, S)
alive(S,X) true if X was allocated in store S
incl (X.A, w, S) ? ( E,f E.f ? w /\ X.A
E.f )
23
Semantic Model Owner Exclusion

• Let p(r) modifies V.a be a method spec.
• Owner exclusion for a call p(x)

ownExcl(x,V.a,S) ?
buf
capacity
q.buf
contents
q.contents

• The pivot field buf of object q can be passed as
  a parameter to method p only if p doesnt have
  permission to modify q.contents .

• Check ownExcl at every call site, and assume it
  at entry to the function

24
Modular checker

• Object store track values of object attributes
  and allocated objects.
• Inclusion relation between locations. track
  compositions of inclusions (transitive).
• Check a function is side-effect correct (Mod)
• Check owner inclusion precondition (ownExcl)
• Check assignments of pivot fields and formal
  parameters
• Check assert statements (effect of function call)
  using Mod.

25
Example
field c field d field f Group g Proc p(t)
modifies t.c.d.g Proc q(u) modifies u.g Impl p
(t) Assume t?null var y in yt.f
q(t.c.d) assert yt.f end
At p function entry ownExcl( t, t.c.d.g, S)
At q function call Mod( u.g, t.c.d.g,
S) ownExcl( u, u.g, S)
At assert Mod( t.f, u.g, S)
26
Conclusion

• Knowing side effects has many applications
• Specifying and checking side effects in modular
  setting is a difficult problem
• Data groups plus alias-confinement restrictions
  provide a solution
• Sound formalization (oolong )
• Implemented checker (oolong )
• Current work build checker for C (with Viktor
  Kuncak)

27
Limitations

• Syntactic aliasing discipline too strict
• Array support not implemented when an object is
  implemented in terms of an array of underlying
  objects.

28
Limitations

• Cyclic dependencies not handled effectively
  infinite looping of Simplify ,the theorem
  prover.

class Node public group g void updateAll()
modifies g private int value in g Node
next maps g into g
void updateAll() value value 1 If (next
! null) next-gtupdateAll()
29

• The End!