1 / 18

Managing Side Effects with Data Groups and Aliasing Restrictions in Modular Design

This presentation discusses the use of data groups and aliasing restrictions to specify and check side effects in a modular and extensible manner. It covers topics such as effect specifications, information hiding, extensibility, and soundness. The concept of ownership versus data groups is explored, along with extensible specifications and the global effect problem.

umeko
Télécharger la présentation

Managing Side Effects with Data Groups and Aliasing Restrictions in Modular Design

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. Using Data Groups to Specify and Check Side Effects K. Rustan M. Leino, Arnd Poetzsch-Heffter, and Yunhong Zhou Presented by Jonathan Aldrich

  2. Outline • The Problem • Checking effects in a modular and extensible way • Data Groups • Aliasing Restrictions • Discussion

  3. Effect Specifications proc p(x,y) modifies x.f,y.g { ... } • Describes the variables p might modify • Uses • Optimizations • Bug finding • Semantics

  4. Specification Challenges proc p(x,y) modifies x.f,y.g { ... } • Information hiding • Don’t want to reveal fields f and g • Extensibility • proc subcls.p(x,y) modifies x.f,y.g,x.h • Soundness • Does p(x,y) modify y.f?

  5. Outline • The Problem • Data Groups • Aliasing Restrictions • Discussion

  6. Data Group • A set of variables and nested data groups • Membership defined incrementally • A field/group can be part of multiple groups // class Collection group state group elems in state field array in elems // class Vector extends Collection field cnt in elems group state group elems field array field cnt

  7. Effect Specifications proc add(coll,o) modifies coll.elems • Information hiding • List data groups rather than fields • Can hide fields behind module interface • Extensibility • Subclasses add new fields to existing groups • So, Vector.add can modify size • What about soundness, expressiveness?

  8. Pivot Fields // class Stack group contents field vec maps elems into contents proc push(stk,o) modifies stk.contents • Provides hierarchy • Effect on vec specified through stk’s group

  9. Outline • The Problem • Data Groups • Aliasing Restrictions • Discussion

  10. Aliasing Problem #1 proc m(st, r) modifies r.obj impl q() { var st := new(); var result := new(); m(st,result); var v := result.obj; var n := v.cnt; push(st, 3); assert (n=v.cnt); } impl m(st, r) { r.obj := st.vec } Modifies v.contents (including v.cnt) if v == st

  11. Pivot Uniqueness • Three restrictions • Pivot fields can only be assigned new or null • Can’t assign a pivot field to anything • This avoid the previous problem • Can pass as parameter • But can’t assign to/from formal parameters • Aliasing Invariant • Pivot fields are unique • Except for formal parameter aliases

  12. Aliasing Problem #2 proc w(st, v) modifies st.contents impl w(st,v) { var n := v.cnt; push(st, 3); assert (n=v.cnt); } w(st, st.vec) Problem: st.vec is available through both st and v in w, but this alias is not obvious in w

  13. Owner Exclusion • Suppose f maps x into g • If p(s) can modify t.g, then s != t.f • In particular, since w(st, v) can modify st.contents, then v != st.vec • Question: how do they verify owner exclusion? • What about w(st1, st2.vec) • where st1 == st2? • I think they would conservatively reject this, even in cases where st1 != st2 • To do better you’d have to track more (non-)aliasing

  14. Outline • The Problem • Data Groups • Aliasing Restrictions • Discussion

  15. Extensible Specifications • Data groups • subclasses add new groups, new fields to existing groups • Ownership • subclasses add new domains, new objects to existing domains • Typestate • subclasses add new typestates, new predicates over added fields

  16. Ownership vs. Data Groups • Data groups can overlap • Allows a field to hold state that is conceptually part of two groups • Ownership is more flexible • Can express iterator, observer idioms • How to specify effects for these idioms?

  17. Ownership for Effect Specs • Some work in this area already • [Clarke & Drossopolou] • Ownership could support iterator effects • Call add on an Iterator in the c.iters domain • Effect is c.elems

  18. S/W Arch. and Effect Specs • Global Effect Problem • Notify callbacks can have large, arbitrary effects • The Achilles' heel of existing effect systems • Specifying all effects does not scale • Specifying global effects causes coupling • Solution: Local Effect Specs? • Specify only the “locally visible” effect within a component • All effects on local and shared data • All calls to external functions • Document assumptions about locally-visible effects of external functions • Component composition must respect assumptions • Global effects computed from local specs + architecture

More Related