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

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

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

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

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

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

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

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

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

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

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

12. analyze programs by analyzing their parts  program modular analysis  heap modular analysis modular shape 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. 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 

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

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

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

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

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

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

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

23. trimming: abstraction t z

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

25.  t z t z

26.  t z t z

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

45. p

46. p p

47. dynamic encapsulation p p p q

48. dynamic encapsulation p p p p q q 

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

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

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

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

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

54. summary parametric shape abstraction dynamic encapsulation  restriction on programs modular shape analysis shape analysis dynamic encapsulation enable verify modular

55. related work modular analysis modular heap analysis shape analysis interprocedural shape analysis encapsulation local reasoning

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

57. future work relax restrictions  richer component-graph structures implementation

58. END use dynamic encapsulation to enable modular shape analysis, use shape analysis to verify dynamic encapsulation

59. fixpoint

60. 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) {... }

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

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

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

64. conditional module invariant program dynamically-encapsulated  module invariant holds

65. partitioned module invariant

68. related work

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

70. ownership types p

71. trace

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

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