1 / 27

Role Analysis

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

persephone
Download Presentation

Role Analysis

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

More Related