Date post: | 15-Jan-2016 |
Category: |
Documents |
Upload: | benedict-jennings |
View: | 216 times |
Download: | 0 times |
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