1 / 73

Modular Shape Analysis for Dynamically Encapsulated Programs

This study explores modular shape analysis for dynamically encapsulated programs to analyze imperative heap-manipulating programs and ensure properties like no memory errors, leaks, or null dereferences.

ellam
Download Presentation

Modular Shape Analysis for Dynamically Encapsulated Programs

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

More Related