Modular shape analysis for dynamically encapsulated programs
Download
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 analysis2

analyze a program by analyzing its parts

scalability

reusability

modular shape analysis

modular 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

...


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

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



Trimming concretization

t

z

t

t

z

z

trimming: concretization





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


abstraction + fixpoint

are we done?


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


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






Manevich et al tacas 07

y

z

y

z

x

Manevich et al.,TACAS’07

x

x

y

z




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