Modular Shape Analysis for Dynamically Encapsulated Programs

Modular Shape Analysisfor Dynamically Encapsulated Programs

Noam Rinetzky Tel Aviv University

Arnd Poetzsch-Heffter Universität Kaiserlauten

Ganesan Ramalingam Microsoft Research India

Mooly Sagiv Tel Aviv University

Eran Yahav IBM Watson

modular shape analysis

shape analysis?

...

modular analysis?


sound static analysis programs

imperative heap-manipulating

properties no memory errors

no memory leaks no null dereferences

shape invariants lists are acyclic

shape analysis

...


analyze a program by analyzing its parts scalability reusability

modular analysis


sound static analysis programs


properties no memory errors

no memory leaks no null dereferences

shape invariants lists are acyclic

analyze a program by analyzing its parts scalability reusability

shape analysis

...

modular analysis

p

analyze programs by analyzing their parts imperative heap-manipulating


qPolygonPolygon List List

PointPoint IntegerInteger

memoryprogram

p

analyze programs by analyzing their partsprogram modular analysisheap modular analysis




program parts memoryprogram memory parts


p

q



PolygonPolygon List List


program part relevant heap parts

p

q










p

q






p

q






program

approach

restrict class of programs to “well behaved” programs dynamically encapsulated programs

compute conditional module invariant approximate “well behaved” clients

use dynamic encapsulation to enable modular shape analysis,

use shape analysis to verify dynamic encapsulation

agenda

setting shape abstraction modular shape analysis

modules simple program model

program = collection of modules module = types + procedures

module level access control

......

Listtype List { Node

hd }type Node { Node n, Point

d}

int foo(List s) { Point p = p.d; int x = getX(p);

}

p.x;

...

...

int getX(Point p) { Integer I = p.x; return value(I);}

Pointtype Point {Integer

x,y }

Point point(int x, int y) {

}

types

procedures

p



PolygonPolygon


module-local state

module can only access parts of the heap comprised of its objects

module-local state

p



module can only access parts of the heap comprised of its objects

components



p

q

sub-heaps objects of one module

maximal connected subheap

outgoing references incoming references

p

q

components



sub-heaps objects of one module

maximal connected subheap

outgoing references incoming references

ListList

PointPoint

p

q

component graphs

nodes: components edges: inter-component references

p



PolygonPolygon


(un)sealed components

unsealed component mutable sealed component immutable

p



PolygonPolygon


trimming abstraction

represents only components of a single module forget other components forget component graph

trimming: abstractiont

z

trimming: concretization

t

z

t

z

t

z

t

z

t

z


t

z

t

z


t

z

t

z

trimming: impossible concretization

bounding abstraction (standard)

q z

trimming

bounding

q

z ...

parametric shape abstraction

concrete states

trimmed states

bounded trimmed states

trimMtrim

M

boundMbound

M


main challenges inferring precondition for inter-module

procedure calls to the moduledetermining effect of inter-module procedure

calls by the module

inter-module procedure calls

sealed component immutable unsealed component mutable



PolygonPolygon


list_proc(p.list, q)

q

p

sealed components

PolygonPolygon


PolygonPolygon

s

list_proc(p.list, q)

e

sealed component immutable inputs to inter-module procedure calls

qListListList List


input: sealed component observation: unmodified since last call


input: sealed component observation: unmodified since last call

module invariant

set of sealed (stable) components in all programs in all executions

all possible inputs to inter-module procedure calls

modular shape analysis infer module invariant analysis

compute input states to inter-module procedure calls

from discovered sealed components

shape analysis within module

discover new sealed components in output states

shapeanalysis

abstraction + fixpoint

are we done?

sanity check

Listtype List { Node hd }type Node { Node n, Point d}

void push(List s, Node e) { e.n = s.hd; s.hd = e;}

...

sanity check

hd n n

d d d

s

d

en



...

sanity check

hd n n

d d d

s

d

en

e



...

main difficulty: unknown usage

unknown heap context returned references incoming references

worst case assumption

complicated analysis expensive analysis non-useful analysis

hd n n

d d d

d

n

our approach

limit inter-component aliasingevery sealed component has a single entry point

q p

limit inter-component aliasingevery sealed component has a single entry point tree of inter-component references

p q

our approach

enque(p,q)challenge: reference parameterssolution: ignore unused references

p q

challenge

verify q is never used!

specify deadnessenque(List s, Node e) // {e}

p q

lightweight annotations

limit inter-component aliasingevery component has a single entry point tree of inter-component references ignoring not to be used references

p q

dynamic encapsulation

dynamic encapsulation p

dynamic encapsulation p p


p q


p p q q

sanity check revisited


void push(List s, Node e) // {e}

{ e.n = s.hd; s.hd = e;}

...

hd n n

d d d

s

d

e


hd n n

d d d

s

d

en

...



{ e.n = s.hd; s.hd = e;}


hd n n

d d d

s

d

en

...



{ e.n = s.hd; s.hd = e;}

our approach

concentrate on well-behaved programs“well behaved” = dynamic encapsulation

modularly checkableprogram P is well behave if all its modules

respect the specification

for every module assume all other modules are well behavedguarantee module is well behaved

verify dynamic encapsulation discover (conditional) module invariants

may not be hold for arbitrary programs

modular analysis

dry run

analysis


List crtList() { ... }

Node crtNode(Point p) // {p }{ ... }

void push(List s, Node e) // { e }

{ ... }

Node pop(List s) { ... }

dry run

analysis





{ ... }


p

p

dry run

analysis





{ ... }


s e

s e

dry run

analysis





{ ... }


s e

s e

...

conditional module invariant program dynamically-encapsulated

module invariant holds

summary

parametric shape abstraction dynamic encapsulation

restriction on programs modular shape analysis

shape analysis dynamic

encapsulation

enable

verify modular

related work

modular analysis modular heap analysis shape analysis interprocedural shape analysis encapsulation local reasoning

Manevich et al., TACAS’07

x x

zy

y z x

y

z

ownership types

p

closely related work

modular heap analysisLogozzo, SAS’03, VMCAI’04

Wies et al., VMCAI’06

encapsulationZaho et al., RTSS’04

Clarke et al., ECOOP’03

modular verificationLeino et al., ESOP’06

future work

relax restrictions richer component-graph structures

implementation

END

use dynamic encapsulation to enable modular shape analysis,

use shape analysis to verify dynamic encapsulation

partitioned module invariant

partitioned module invariant

Documents

Modular Shape Analysis for Dynamically Encapsulated Programs