ownership, encapsulation and the disjointness of type and effect dave clarke, sophia...

Ownership, Encapsulation and the Disjointness of Type and

EffectDave Clarke, Sophia Drossopoulou/2002

Encapsulation seminar

Dec 1 2005Sharon Goldschlager

2

Aim

Static reasoning about the program.

• Aliasing.

• Non-interference of expressions.

3

Road Map

• Aim

• Aliasing to previous lectures

• General Idea

• Basic definitions

• Static rules

• Dynamic rules

• Summary

4

Aliasing to previous lectures

• Islands(Hogg) – prevent static(heap) aliasing using read(destructive) only references, access through a single bridge.

• Confined types(Bokowski) relate to security – all references are confined to preset space.

• These methods impose great limitations on the programmer, implementation overhead – cannot have direct reference.

5

General Idea

• Encapsulation – placing boundary around object properties.

• Boundary of ownership, instead of containment.

• Extension of Ownership with effects and effect shapes.

• Ownership instead of uniqueness.

6

Ownership• Owner(context) - another

object, “Container”.

• Object’s Representation – the objects it owns.

• Induces tree-shaped ordering.

• owners-as-dominators, all paths from the root of the object graph to an object pass through its owner.

7

Context and Classes

• Classes parameterized by context, subclasses keep owner.

• Types c<context param list>.

• Context – in text source (p).– Actual – per object (k) in run time.– Variables (z).– this (owner of representation).– world – root context.

8

Exampleclass List<owner,data> { Link<this,data> head; void add(Data<data> d) writes under(this) { head = new Link<this,data>(d, head); }}

class Main<> { List<this,world> list; Main() writes this { list = new List<this,world>; } void populate() writes under(this.1) { list.add(new Data<world>); list.add(new Data<world>); } static void main() writes under(world) { Main<> main = new Main<>; main.populate(); }}

this is current object.

1st parameter is owner context.

No parameter means World is the owner.

Owner this restricts access to current object and objects inside it.

no reference into the inside.

9

Representation

• Representation – objects owned by this.• Representation context – representation of

context.• Example representation of previous program:

10

Simple Alias Deduction using Ownership

List<this,world> shared;

List<this,this> encaps;

• Shared, encaps cannot be aliases.

• Their Link objects are disjoint.

• Their Data objects are disjoint.

11

Method Effects And Their Shapes

• Effect can be read or write (implying read).• Shape denotes collection of contexts.• Methods must specify (1 or 2) <effect,shape> pairs.• Examplevoid exmpl_method() reads p writes under p.2{ … }

12

Dynamic Aliasing

• Dynamic aliases - created during program execution when a reference is changed (iterator).

• Break (briefly) owners-as-dominators for stack, local variables.

bool equals(List<owner,data> other) {

Link<this,data> thislink = this.head;

Link<other,data> otherlink = other.head;

... thislink.data.equal(otherlink.data) ...

}

13

Dynamic Aliasing • owners-as-dominators property

enforces deep ownership.

• Type of each dynamic alias contains the name of the aliased representation entity.

List<p,world> list = new List<p,world>;

Iterator<list,world> iter = list.makeIterator();

• Conclusion

Dynamic aliases cannot be stored in an object’s field.

14

Formalism Notation - Static

15

Formalism Notation - Dynamic

• ActualContext – world and one for each object created.

16

Semantics Blocks

• Environment E assigns types to free variables, locations, context variables constraints.

• Binding B map context variables to actual

Contexts, and variables to values.

17

Formalism Notation

18

• means directly inside.

• is the transitive closure of .

• is the reflexive transitive closure of .

Context Relations

• Relational inclusion

19

Valid Contexts

• CTX-VAR: context variable should be related to a context.

• CTX-REP: variable/location may denote representation context.

• CTX-WORLD: world is a valid context.

20

Context Ordering

Representation context directly inside owner

Relational composition

21

Effect Shapes

22

Subshaping Set Rules

Simple

set theory

properties.

23

Subshaping Geometric Rules

• SUBSHAPE-UNDER: ordering of under effects, under effect at a particular level contains all deeper under effects.

24

Effects and Subeffecting

Subeffect

Write imply read

25

Type Rules

26

Values

• VAL-NULL: null can have any type.

• VAL-W: Type of variables, locations as in environment.

• EXP-FROMVAL: variable can be seen as expression with no effect.

27

Expressions

• EXPR-NEW: Produces no effect.• EXP-FIELD: Type of expression is field type with

parameter substitution.• EXR-UPDATE: Likewise, rhs,lhs matching types.

28

Let Expression Dynamic Alias

Effect rd x, x not in scope at end

under-approximation: super-effect rd a.1.

What’s the effect of

29

Expressions

• EXP-SUB: Expression of some type is of its super-type, and effect need not be accurate.

• EXP-CALL: Matching of types, and binding of formal-actual parameter.

30

Inheritance Rules

31

Method, Program

• PROG: Well-formed program contains only well-formed classes.

• METHOD: Type, effect of body match

declaration.

32

Extension Lemma

• E’>>E: E’ extends E, i.e. E is subsequence in E’.

• B’>>B: B’ extends B, i.e. B is subsequence in B’.

Lemma: Assume E:B├ ή• If E’>>E and E’:B├ ◊, then E’:B├ ή.

(extention)• If B’>>B and E:B’├ ◊, then E:B’├ ή.

(substitution)

33

Dynamic Notation

CMAP: map from class context parameters where method m is declared to the actual contexts, for correct evaluation of the method body e.

34

• Evaluation relation

an expression configuration to a final configuration.

Dynamic Relations

• Computation relation

a computation configuration to a final configuration.

35

Evaluation Rules

• EV-LET: 1st computation, bind value to x, then evaluate expression

with new heap, binding.

• EV-VAR: Variables - lookup in binding list.

36

Computation Rules - Field

• COMP-FIELD: Effect reading object in i.

• COMP-UPDATE: Write value to field.

Effect writing object in i.

37

Computation Rules - New

• COMP-NEW: New heap location bound to object. Fields initialized to null.

• Object type is determined by parameter lookup in binding list B.

• No effect!

38

Computation Rules - Call

• COMP-CALL: object from binding, determine type c<..>, method lookup.

Binding of class parameters to actual, this, method formal parameter to actual’s value.

39

Reasoning Basics

• Fields/variables of disjoint types cannot be aliases.

• Disjointness of effect shapes determine whether expressions potentially interfere.

Disjointness according to

• Tree-shaped partial order.• Non-overlapping places in the inheritance

hierarchy.

40

Disjointness Notation

Rules are valid for all valid bindings B of free variables.

41

Disjointness of Context

• DCTX-NEQ: Different related context are not equal.

• DCTX-TYPE: Representation context of non-aliases are disjoint.

• DCTX-LOC: Disjoint locations – clearly.

42

Disjointness of Type

• DTYPE-CLASS: Non inherited – disjoint.

• DTYPE-CTX: Same position argument.

• DTYPE-SUB: Subtypes preserve disjointness.

43

Disjointness of Effect Shape

Based on Set theory.• DFX-0: Good effect shape disjoint from empty.• DFX-SUB: Subshape of a disjoint is also disjoint.• DFX-UNION: Union of shapes disjoint to other,

is disjoint.

44

Disjointness of Effect Shape

45

Effect Shapes Based Non-Interference Deduction

• Interference - one reads, another writes or both write to same location.

• Expressions with non-interfering effects imply non-interfering execution:

the evaluation order is immaterial, same results, same heap.

46

Non-Interference Example

Assume E p#q

E list<p,world>#list<q,world>

wr under(list1)#wr under list2

47

Deduction Implications

• Loop fusion leads to optimization.

48

Summary of Contributions

• Ownership as basis for reasoning.

• Support inheritance and dynamic aliases.

• Computational effects.

• Aliasing and interference deduction.

• Formal semantics and analysis framework.

49

The End