Modular Shape Analysis for Dynamically Encapsulated Programs

Modular Shape Analysisfor Dynamically Encapsulated Programs Noam Rinetzky Tel Aviv University Arnd Poetzsch-Heffter UniversitätKaiserlauten Ganesan Ramalingam Microsoft Research India Mooly Sagiv Tel Aviv University Eran Yahav IBM Watson

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

sound static analysis programs imperative heap-manipulating properties no memory errors no memory leaks no null dereferences shape invariants lists are acyclic modular shape analysis shape analysis ...

analyze a program by analyzing its parts scalability reusability modular 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 analyze a program by analyzing its parts scalability reusability modular shape analysis modular analysis shape analysis ...

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

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

modular shape analysis • analyze programs by analyzing their parts • program modular analysis • heap modular analysis p Polygon List q Point Integer  program part relevant heap parts

modular shape analysis • analyze programs by analyzing their parts • program modular analysis • heap modular analysis p  Polygon List q Point Integer program part relevant heap parts

modular shape analysis • analyze programs by analyzing their parts • program modular analysis • heap modular analysis p Polygon List  q Point Integer program part relevant heap parts

modular shape analysis • analyze programs by analyzing their parts • program modular analysis • heap modular 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

types procedures modules • simple program model • program = collection of modules • module = types + procedures • module level access control Point type Point {Integer x,y } Pointpoint(int x, int y) { } List type List { Node hd } type Node { Node n, Pointd} int foo(List s) { Pointp = p.d; int x =getX(p); } ... int getX(Point p) { Integer I = p.x; return value(I); }  p.x; ... ... ...

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

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

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

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

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

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

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

trimming: abstraction t z

t z t t z z trimming: concretization 

trimming: concretization t z  t z

trimming: impossible concretization t z   t z

q ... z bounding abstraction (standard) q z trimming bounding

trim trim M M bound bound M M parametric shape abstraction concrete states trimmed states bounded trimmed states

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 list_proc(p.list, q) p Polygon Polygon List q Point Point Integer Integer

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

inter-module procedure calls • 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

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

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; } ...

s e 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; } n hd n n d d d d ...

s e e 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; } n hd n n d d d d ...

unknown heap context returned references incoming references worst case assumption complicated analysis expensive analysis non-useful analysis main difficulty: unknown usage n hd n n d d d d

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

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

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

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

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

dynamic encapsulation p

dynamic encapsulation p p 

dynamic encapsulation p p   q p

dynamic encapsulation p p   q p p q  

Modular Shape Analysis for Dynamically Encapsulated Programs