Modular Shape Analysis for Dynamically Encapsulated Programs Noam Rinetzky Tel Aviv University Arnd Poetzsch-HeffterUniversität Kaiserlauten Ganesan RamalingamMicrosoft Research India Mooly Sagiv Tel Aviv University Eran Yahav IBM Watson

modular shape analysis shape analysis?... modular analysis?

modular shape 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...

modular shape analysis analyze a program by analyzing its parts  scalability  reusability modular analysis

modular shape analysis sound static analysis programs  imperative  heap-manipulating 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 modular shape analysis q Polygon List Point Integer memory program

p analyze programs by analyzing their parts  program modular analysis  heap modular analysis modular shape analysis q Polygon List Point Integer program parts memory program memory parts  imperative  heap-manipulating

p q analyze programs by analyzing their parts  program modular analysis  heap modular analysis modular shape analysis Polygon List Point Integer program partrelevant heap parts

p q analyze programs by analyzing their parts  program modular analysis  heap modular analysis modular shape analysis Polygon List Point Integer program partrelevant heap parts

analyze programs by analyzing their parts  program modular analysis  heap modular analysis modular shape analysis Polygon List Point Integer p q program partrelevant heap parts

analyze programs by analyzing their parts  program modular analysis  heap modular analysis modular shape analysis Polygon List Point Integer p q program partrelevant heap parts

analyze programs by analyzing their parts  program modular analysis  heap modular analysis modular shape analysis Polygon List Point Integer 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... List type 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); } Point type Point {Integer x,y } Point point(int x, int y) { } types procedures 

p q Polygon List Point Integer Polygon Point Integer module-local state module can only access parts of the heap comprised of its objects

module-local state p q Polygon List Point Integer module can only access parts of the heap comprised of its objects

components Polygon List Point Integer p q sub-heaps  objects of one module maximal connected subheap  outgoing references  incoming references p q

components Polygon List Point Integer sub-heaps  objects of one module maximal connected subheap  outgoing references  incoming references List Point p q

component graphs nodes: components edges: inter-component references p q Polygon List Point Integer Polygon Point Integer

(un)sealed components unsealed component mutable sealed component immutable p q Polygon List Point Integer Polygon Point Integer

trimming abstraction represents only components of a single module  forget other components  forget component graph

trimming: abstraction t 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  trim M  trim M  bound M  bound M

modular shape analysis main challenges  inferring precondition for inter-module procedure calls to the module  determining effect of inter-module procedure calls by the module

inter-module procedure calls sealed component immutable unsealed component mutable Polygon List Point Integer Polygon Point Integer list_proc(p.list, q) q p

sealed components Polygon Point Integer Polygon s list_proc(p.list, q) e sealed component immutable inputs to inter-module procedure calls q List

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 shape analysis

abstraction + fixpoint are we done?

sanity check List type 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 dd d s d e n List type 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 dd d s d e n e List type List { Node hd } type Node { Node n, Point d} void push(List s, Node e) { e.n = s.hd; s.hd = 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 dd d d n

our approach limit inter-component aliasing  every sealed component has a single entry point q p

limit inter-component aliasing  every sealed component has a single entry point  tree of inter-component references p q our approach

enque(p,q)  challenge: reference parameters  solution: ignore unused references p q challenge verify q is never used!

specify deadness  enque(List s, Node e) // {e} p q lightweight annotations

limit inter-component aliasing  every component has a single entry point  tree of inter-component references  ignoring not to be used references p q dynamic encapsulation

p

p p

dynamic encapsulation p p p q

dynamic encapsulation p p p p q q 

sanity check revisited List type List { Node hd } type Node { Node n, Point d} void push(List s, Node e) // {e} { e.n = s.hd; s.hd = e; }... hd n n dd d s d e

sanity check revisited hd n n dd d s d e n... List type List { Node hd } type Node { Node n, Point d} void push(List s, Node e) // {e} { e.n = s.hd; s.hd = e; }

sanity check revisited hd n n dd d s d e n... List type List { Node hd } type Node { Node n, Point d} void push(List s, Node e) // {e} { e.n = s.hd; s.hd = e; }

our approach concentrate on well-behaved programs  “well behaved” = dynamic encapsulation modularly checkable  program P is well behave if all its modules respect the specification

for every module  assume all other modules are well behaved  guarantee module is well behaved verify dynamic encapsulation discover (conditional) module invariants  may not be hold for arbitrary programs modular analysis

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

closely related work modular heap analysis  Logozzo, SAS’03, VMCAI’04  Wies et al., VMCAI’06 encapsulation  Zaho et al., RTSS’04  Clarke et al., ECOOP’03 modular verification  Leino 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

fixpoint

dry run analysis List type List { Node hd } type Node { Node n, Point d} List crtList() {... } Node crtNode(Point p) // {p } {... } void push(List s, Node e) // { e } {... } Node pop(List s) {... }

dry run analysis List type List { Node hd } type Node { Node n, Point d} List crtList() {... } Node crtNode(Point p) // {p } {... } void push(List s, Node e) // { e } {... } Node pop(List s) {... } p p

dry run analysis List type List { Node hd } type Node { Node n, Point d} List crtList() {... } Node crtNode(Point p) // {p } {... } void push(List s, Node e) // { e } {... } Node pop(List s) {... } s e s e

dry run analysis List type List { Node hd } type Node { Node n, Point d} List crtList() {... } Node crtNode(Point p) // {p } {... } void push(List s, Node e) // { e } {... } Node pop(List s) {... } s e s e...

conditional module invariant program dynamically-encapsulated  module invariant holds

partitioned module invariant

related work

Manevich et al., TACAS’07 x x z y y z x y z

ownership types p

trace

inter-module procedure calls input: sealed component observation: unmodified since last call

inter-module procedure calls input: sealed component observation: unmodified since last call