Modular Shape Analysis for Dynamically Encapsulated Programs

1. 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

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

3. 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 ...

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

5. 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 ...

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

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

8. 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

9. 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

10. 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

11. 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

12. modular shape analysis • analyze programs by analyzing their parts • program modular analysis • heap modular analysis  Polygon List   Point Integer   program

13. 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

14. agenda • setting • shape abstraction • modular shape analysis

15. 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; ... ... ...

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

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

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

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

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

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

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

23. trimming: abstraction t z

24. t z t t z z trimming: concretization 

25. trimming: concretization t z  t z

26. trimming: concretization t z  t z

27. trimming: impossible concretization t z   t z

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

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

30. 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

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

32. 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

33. module invariant • set of sealed (stable) components • in all programs • in all executions • all possible inputs to inter-module procedure calls

34. 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

35. abstraction + fixpoint are we done?

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

37. 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 ...

38. 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 ...

39. 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

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

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

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

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

44. 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

45. dynamic encapsulation p

46. dynamic encapsulation p p 

47. dynamic encapsulation p p   q p

48. dynamic encapsulation p p   q p p q  

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

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