modular shape analysis for dynamically encapsulated programs
Download
Skip this Video
Download Presentation
Modular Shape Analysis for Dynamically Encapsulated Programs

Loading in 2 Seconds...

play fullscreen
1 / 73

Modular Shape Analysis for Dynamically Encapsulated Programs - PowerPoint PPT Presentation


  • 95 Views
  • Uploaded on

Modular Shape Analysis for Dynamically Encapsulated Programs. Noam Rinetzky Tel Aviv University Arnd Poetzsch-Heffter Universität Kaiserlauten Ganesan Ramalingam Microsoft Research India Mooly Sagiv Tel Aviv University Eran Yahav IBM Watson. modular shape analysis.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Modular Shape Analysis for Dynamically Encapsulated Programs' - mercer


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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 shape analysis

modular analysis?

shape analysis?

...

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

...

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

...

slide6

p

q

modular shape analysis

  • analyze programs by analyzing their parts
    • imperative
    • heap-manipulating

Polygon

List

Point

Integer

memory

program

slide7

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

slide8

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

slide9

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

slide10

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

slide11

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

slide12

modular shape analysis

  • analyze programs by analyzing their parts
    • program modular analysis
    • heap modular analysis

Polygon

List

Point

Integer

program

approach
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
agenda
  • setting
  • shape abstraction
  • modular shape analysis
modules

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-local state
  • module can only access parts of the heap comprised of its objects

p

Polygon

Polygon

List

q

Point

Point

Integer

Integer

module local state1

p

Polygon

List

q

Point

Integer

module-local state
  • module can only access parts of the heap comprised of its objects
components

p

q

p

q

components
  • sub-heaps
    • objects of one module
      • maximal connected subheap
    • outgoing references
    • incoming references

Polygon

List

Point

Integer

components1
components
  • sub-heaps
    • objects of one module
      • maximal connected subheap
    • outgoing references
    • incoming references

p

Polygon

List

List

q

Point

Integer

Point

component graphs
component graphs
  • nodes: components
  • edges: inter-component references

p

Polygon

Polygon

List

q

Point

Point

Integer

Integer

un sealed components
(un)sealed components
  • unsealed component mutable
  • sealed component immutable

p

Polygon

Polygon

List

q

Point

Point

Integer

Integer

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

q

...

z

bounding abstraction (standard)

q

z

trimming

bounding

parametric shape abstraction

trim

trim

M

M

bound

bound

M

M

parametric shape abstraction

concrete states

trimmed states

bounded trimmed states

modular shape analysis4
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
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 components
  • sealed component immutable
  • inputs to inter-module procedure calls

list_proc(p.list, q)

Polygon

Polygon

List

List

e

q

s

Point

Integer

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

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
sanity check
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 check1

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

...

sanity check2

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

...

main difficulty unknown usage
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

our approach

q

p

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

q

p

challenge
challenge
  • enque(p,q)
    • challenge: reference parameters
    • solution: ignore unused references

verify q is never used!

q

p

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

q

p

dynamic encapsulation
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 encapsulation3
dynamic encapsulation

p

p

q

p

dynamic encapsulation4
dynamic encapsulation

p

p

q

p

p

q

sanity check revisited

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

...

sanity check revisited1

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

...

sanity check revisited2

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

...

our approach2
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
modular analysis
modular analysis
  • 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
summary
summary
  • parametric shape abstraction
  • dynamic encapsulation
    • restriction on programs
  • modular shape analysis

enable

dynamic encapsulation

modular

verify

shape analysis

related work
related work
  • modular analysis
  • modular heap analysis
  • shape analysis
  • interprocedural shape analysis
  • encapsulation
  • local reasoning
closely related work
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
future work
  • relax restrictions
    • richer component-graph structures
  • implementation
slide58
END

use dynamic encapsulation to enable modular shape analysis,

use shape analysis to verify dynamic encapsulation

dry run
dry run

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)

{ ... }

analysis

dry run1

p

p

dry run

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)

{ ... }

analysis

dry run2

e

s

dry run

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)

{ ... }

e

s

analysis

dry run3

...

e

s

dry run

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

analysis

conditional module invariant
conditional module invariant
  • program dynamically-encapsulated

 module invariant holds

inter module procedure calls1
inter-module procedure calls
  • input: sealed component
  • observation: unmodified since last call
inter module procedure calls2
inter-module procedure calls
  • input: sealed component
  • observation: unmodified since last call
ad