Role Analysis

Victor Kunkac, Patric Lam, Martin Rinard

Laboratory for Computer Science, MIT

Presentation by George Caragea

CMSC631, 11.06.2003

What is a role system?

• Extension of the type system– Runs at compile time

• Roles change during execution of the program

• Roles capture both properties that change and the ones which don’t

• Inter and intraprocedural analysis

Why roles?

• Express data structure consistency properties

• Improve precision of procedure interface specifications

• Express precise referencing and interaction behaviors between objects

• Express constraints on movement of objects between data structures

Roles and aliases

• The role of an object depends on the data structures in which it participates

• The role declaration provides complete aliasing information– It identifies the complete set of references to

that object

• Roles allow multiple aliases to be statically checked

Example

Process scheduler – Role reference diagram

Role definition language

• Role systems involves extra work– Annotations, specification files

• Language expresses – data structure invariants – data structure participation– consistency properties– interface changes

Role definitionsrole LiveHeader {

fields next : LiveList I null;

}

role LiveList {fields next : LiveList I null,proc : RunningProc I SleepingProc;slots LiveList.next I LiveHeader.next;acyclic next;

}

Role definitions (cont’d)

role RunningProc {

fields

next : RunningProc I RunningHeader,

prev : RunningProc I RunningHeader;

slots

RunningHeader.next I RunningProc.next,

RunningHeader.prev I RunningProc.prev,

LiveList.proc;

identities

next.prev,

prev.next;

}

Role definitions (cont’d)

role SleepingProc {

fields

left : SleepingProc I null,

right : SleepingProc I null;

slots

SleepingProc.left I SleepingProc.right I SleepingHeader.root;

LiveList.proc;

acyclic

left, right;

}

Roles and procedure interfaces

• Must specify initial and final roles of the parameters

• Must specify read and write effects

• If the procedures fails to perform the specified goals, role system will signal

procedure suspend(p: RunningProc ->> SleepingProc,s: SleepingHeader)

effects!(p.prev = null), !(p.next = null),(RunningProc I RunningHeader) . (prev l next) =

(RunningProc I RunningHeader),!(s.root = p), !(p.left = SleepingProc I null);

vat pp, pn, r;{

pp = p.prev; pn = p.next;r = s.root;p.prev = null; p.next = null;pp.next = pn; pn.prev = pp;s.root = p; p.left = r;

}

Procedure interface example

Syntax and semantics

• The concrete heap = a finite directed graph – Nodes – objects in the heap– Edges – heap references

• Example: a reference from object o1 with field f to object

o2

cH

cHofo ),,( 21

Syntax and semantics (cont’d)

• Set of roles used: R,– denotes null object

• Set of all fields: F• A role is a conjunction of the constraints:

– Fields: – Slots:– Identities:– Acyclicities:

Rnull cnull

02: Rf Rfield

FRrslotk )(FFridentities )(

Fracyclic )(

0R

• Concrete role assignment

• A heap is role consistent iff there exists a role assignment such that for every the predicate is satisfied.

• formalizes the constraints associated with the definition.– e.g. For every field , if then

0)(: RHnodes cc

Syntax and semantics (cont’d)

c )( cHnodeso),,( ccHosistentlocallyCon

),,( ccHosistentlocallyCon

Ff

)()( rfieldo fc cHofo ,,

Onstage / Offstage objects

• We must allow temporary violations of the role constraints

• We partition the set of heap objects:– onstage(Hc) : referenced by a local variable or

parameter– offstage(Hc) : the rest.

• Onstage object need not have correct roles• Re-define

for ),,,( ccc SHosistentlocallyCon

)( cc HnodesS

The programming model

We assume a simple, imperative language• Statements

– Load: x=y.f– Store: x.f=y– Copy: x=y– New: x=new– test

• Procedures– Procedures change the global heap but don’t return

values

The abstraction relation

• Due to on- and offstage reachability distinctions, we need a more precise representation

• The analysis representation is an abstract role graph G which represents a concrete role assignment

• α – abstraction relationGH cc ),(

Intraprocedural role analysis

• Role consistency for the concrete heap Hc can be verified incrementally by ensuring role consistency for every node when it goes offstage

• Analysis is modeled as a dataflow analysis

• Dataflow fact G is a set of role graphs

Intraprocedural role analysis (cont’d)

• Analysis operates on the lattice P(RoleGraphs) of sets of role graphs with set union as the join operator

• Bottom role graph represents set of all concrete heaps including

• The heap can be represented only by G

cerrorG

cerror

Intraprocedural role analysis (cont’d)

• We need transfer functions for each of the statements in the imperative language

Intraprocedural role analysis (cont’d)

The program does not violate the role constraints if is not reachable.

The dataflow analysis algorithm establishes this.

G

Interprocedural analysis

The transfer function of a procedure is given by the:

• Initial context

• Set of effects

Interprocedural analysis (cont’d)

Two steps:• Verifying procedure interfaces

– Creating role graphs at procedure entry– Verifying basic statements– Verifying procedure postconditions

• Analyzing call sites– Parameter check– Context matching– Effect instantiation– Role reconstruction

Conclusions

• Aliasing relationships should determine, in part, the type of each object

• The type system should use the resulting object states as its fundamental abstraction

Conclusions (cont’d)

Uses of role systems

• Ensure correctness of procedure interfaces

• Verify data structure consistency properties

• Check correct implementation of relationships between objects

• ...

The End

• Questions?– Be easy on me, I didn’t write it!

Abstraction Example