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 elems group state 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