Role Analysis

1. Role Analysis Victor Kunkac, Patric Lam, Martin Rinard Laboratory for Computer Science, MIT Presentation by George Caragea CMSC631, 11.06.2003

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

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

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

5. Example Process scheduler – Role reference diagram

6. Role definition language • Role systems involves extra work • Annotations, specification files • Language expresses • data structure invariants • data structure participation • consistency properties • interface changes

7. Role definitions role 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; }

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

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

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

11. Procedure interface example 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; }

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

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

14. Syntax and semantics (cont’d) • 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

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

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

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

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

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

20. Intraprocedural role analysis (cont’d) • We need transfer functions for each of the statements in the imperative language

21. Intraprocedural role analysis (cont’d) The program does not violate the role constraints if is not reachable. The dataflow analysis algorithm establishes this.

22. Interprocedural analysis The transfer function of a procedure is given by the: • Initial context • Set of effects

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

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

25. Conclusions (cont’d) Uses of role systems • Ensure correctness of procedure interfaces • Verify data structure consistency properties • Check correct implementation of relationships between objects • ...

26. The End • Questions? • Be easy on me, I didn’t write it!

27. Abstraction Example