alias types
Post on 30-Dec-2015
90 Views
Preview:
DESCRIPTION
TRANSCRIPT
Alias Types
David Walker
Cornell University
What do you want to type check today?
April 12, 2000
David Walker, Cornell University 2
Types in CompilationTerms Types
Typed Source
Typed Intermediate
Typed Target
• Type-preserving compilers [Java,Til(t),Touchstone,Popcorn]
– produce certified code– improve reliability & security
April 12, 2000
David Walker, Cornell University 3
High-level vs Low-level
• Typed high-level languages– simple & concise
• programmers must be able to diagnose errors• type inference improves productivity
• Typed low-level languages – expressive
• capable of encoding multiple source languages• capable of encoding multiple compilation strategies• may focus on checking rather than inference
April 12, 2000
David Walker, Cornell University 4
Memory Management
• Typed high-level languages – simple & concise
• automatic memory management
• Typed low-level languages– expressive
• support for alternative memory management techniques, compiler optimizations
• explicit memory allocation, initialization, recycling, and deallocation
April 12, 2000
David Walker, Cornell University 5
Goals
• Study memory management invariants
• Make invariants explicit in a type system– provide compiler writers, systems hackers
with flexibility & safety
• Today– one particular type system
April 12, 2000
David Walker, Cornell University 6
Hazards• When memory is recycled, it may be used to store objects of different types
• x must not be used an integer reference
3
x
3
free_list
free(x) let y = <x.x>x
y
x
x.x
April 12, 2000
David Walker, Cornell University 7
MM Tradeoffs• Safe memory management involves deciding
amongst tradeoffs:– aliasing: are multiple references to an object allowed?– first-class: where can references be stored?– reuse: can memory be reused at different types?
Aliasing
First-class
Reuse
April 12, 2000
David Walker, Cornell University 8
ML Refs
• Unlimited aliasing• First-class• Limited reuse
– refs obey the type invariance principle– reuse is limited to objects of the same type
• explicit deallocation is disallowed
Aliasing
First-class
Reuse
•
April 12, 2000
David Walker, Cornell University 9
Stack Allocation
• Unlimited reuse• Some aliasing• Not first-class• Examples
– algol, stack-based (typed) assembly language
Aliasing
First-class
Reuse
•
April 12, 2000
David Walker, Cornell University 10
Linear Typing
• Immediate reuse • First-class• No aliasing
– one reference to an object of linear type
Aliasing
First-class
Reuse•
April 12, 2000
David Walker, Cornell University 11
Alias Types
• Unlimited reuse• First-class• Some aliasing
Aliasing
First-class
Reuse
•
April 12, 2000
David Walker, Cornell University 12
Outline
• Alias types [with Fred Smith, Greg Morrisett]
– The basics: concrete store types • Types for describing store shape• Type checking
– Abstraction mechanisms• Polymorphic, Existential & Recursive types
• Wrap-up– Implementation & research directions
April 12, 2000
David Walker, Cornell University 13
Alias Analysis
• Alias analysis– the problem of discovering aliasing relationships in
unannotated programs (often in a subset of C)– goals:
• program optimization• uncovering hazards in unsafe programs
– vast literature: Jones & Muchnick, Deutsche, Ghiya & Hendren, Steensgaard, Evans, Sagiv & Reps & Wilhelm, ...
April 12, 2000
David Walker, Cornell University 14
Our Problem
• Checking aliasing & typing in safe languages– used in a certifying compiler – integrated with a rich type system (TAL)
• typing and aliasing are inter-dependent• aliasing relationships encoded using types• can express dependencies between functions & data• sound: standard proof techniques imply type safety
[Wright & Felleisen]
April 12, 2000
David Walker, Cornell University 15
Linear Types
• Linear types ensure there is one access path to any memory object
• A single-use constraint preserves the invariant
2 5 7
x
5 7z
y = 2
2x is implicitly recycled:
x'
x : int (int int)
x : int (int int)let y,z = x in ...y : int, z : (int int)
April 12, 2000
David Walker, Cornell University 16
Aliasing
• User data structures involve aliasing:– circular lists, queues, ...
• Compilers introduce more aliasing:– displays, some implementations of exceptions– transformations/optimizations: register allocation,
destination-passing style• Bottom line:
– There are countless situations in which the single access path invariant is too restrictive
April 12, 2000
David Walker, Cornell University 17
Alias Types
• Main idea: split an object type into two parts– an address (a "name" for the object)
• multiple occurrences represent aliasing, multiple access paths
– a type describing object contents
0x3466
address memory/object contents
<int,int>
April 12, 2000
David Walker, Cornell University 18
Store Types
• Store types
• Store type composition
4l1: 7{l1 <int,int>}
4l1: 7{l1 <int,int>} {l2 <int,int>} {l3 <int,int>}
1l2: 2
9l3: 8
April 12, 2000
David Walker, Cornell University 19
Store Types
• Store component types are unordered:
• No aliasing/duplication of store types– one type associated with each address– no contraction rule
{l1 <int,int>} {l1 <int,int>} {l1 <int,int>}
{l1 <int>} {l2 <char>} = {l2 <char>} {l1 <int>}
April 12, 2000
David Walker, Cornell University 20
Aliasing
• Pointers have singleton type– x : ptr(l1)
– "x points to the object at address l1"
– aliases == pointers to objects with the same name
– eg: x : ptr(l1), y : ptr(l1)
x
y
l1:
April 12, 2000
David Walker, Cornell University 21
Aliasing
• A dag:{ l1 <int,ptr(l3)> }
{ l2 <char,ptr(l3)> }
{ l3 <int,int> }
x : ptr(l1), y : ptr(l2)
• A cycle:{ l1 <int,ptr(l1)> }
5 74x
y 'a'
4
April 12, 2000
David Walker, Cornell University 22
Type Checking
• Store types vary between program points:
{ l1 1 } { l2 2 } ...instruction{ l1 1' } { l2 2 } ...instruction{ l1 1' } { l2 2' } ...
April 12, 2000
David Walker, Cornell University 23
Example
• Initializing data structures:
{ l <Top,Top> }, x : ptr(l)x.1 := 3;{ l <int,Top> }, x : ptr(l)x.2 := 'a';{ l <int,char> }, x : ptr(l)
?x ?
3x ‘a’
April 12, 2000
David Walker, Cornell University 24
Example
• Use of a pointer requires proper store type:
{ l1 <int,int> }, x:ptr(l1)let z = x in
{ l1 <int,int> }, x:ptr(l1), z:ptr(l1)free (z);
, x:ptr(l1), z:ptr(l1)let w = x.1 in % Wrong: l1 not present in store....
4x 3
?
4x 3
z
x
z
April 12, 2000
David Walker, Cornell University 25
Functions
• Function types specify input & output store:
• A call site:
• Technical note: calculus formalized in continuation-passing style
f : { l1 <int,int> }.1 { l1 <char,char> }.2
{ l1 <int,int> }, x : 1
let y = f (x) in
{ l1 <char,char> }, x : 1,y : 2
...
April 12, 2000
David Walker, Cornell University 26
Outline
• Alias types [with Fred Smith, Greg Morrisett]
– The basics: concrete store types • Types for describing store shape• Type checking
– Abstraction mechanisms• Polymorphic, Existential & Recursive types
• Wrap-up– Implementation & research directions
April 12, 2000
David Walker, Cornell University 27
Location Polymorphism
– Only concrete location 0x12 can be dereferenced
– Add location polymorphism:
– The dependence between pointer and memory block is preserved
deref: { 0x12 <int> }.ptr(0x12) { 0x12 <int> }.int
deref: [1].{ 1 <int> }.ptr(1) { 1 <int> }.int
April 12, 2000
David Walker, Cornell University 28
Example
deref: [1].{ 1 <int> }.ptr(1) { 1 <int> }.int
let , x = new(1) in{ <Top> }, x : ptr() x.1 := 3;{ <int> }, x : ptr()let y = deref [] (x) in{ <int> }, x : ptr(), y : int 0x12:
– From now on, I will stop mentioning concrete locations
3X
April 12, 2000
David Walker, Cornell University 29
Another Difficulty
• Currently, deref can only be used in a store with one reference:
deref: [1].{ 1 <int> }.ptr(1) { 1 <int> }.int
let , x = new(1) in x.1 := 3;let ', y = new(1) in y.1 := 7;{ <int> } { ' <int> }let _ = deref [] (x) ...% { <int>} {' <int>} { <int>}
April 12, 2000
David Walker, Cornell University 30
Subtyping?
– Subtyping (weakening) makes store components unusable:
deref: [1].{ 1 <int> }.ptr(1) { 1 <int> }.int
{ <int> } { ' <int> } { <int> }let _ = deref [] (x) in{ <int> } % ' inaccessible
April 12, 2000
David Walker, Cornell University 31
Store Polymorphism
– Store polymorphism hides store size and shape from callee & preserves it across the call
deref: [,1]. { 1 <int> }.ptr(1) { 1 <int> }.int
store preserved across the call
April 12, 2000
David Walker, Cornell University 32
Example
x: ptr(), y: ptr('),{ <int> } { ' <int> }let _ = deref [{ ' <int> },] (x) in % OK{ <int> } { ' <int> }let _ = deref [{ <int> },'] (y) in % OK{ <int> } { ' <int> }
deref: [,1]. { 1 <int> }.ptr(1) { 1 <int> }.int
– deref may be called with different references and preserves the store at each step:
April 12, 2000
David Walker, Cornell University 33
Example: A stack
foo:[,sp,caller]. {sp <int,ptr(caller)>} . ptr(sp) ....
stack framestack pointer
pointer tocaller's frame
rest of the stack
sp:
caller:
function argument on stack
• O'Hearn & Reynolds• Stack-based TAL
April 12, 2000
David Walker, Cornell University 34
Aliasing
• Simple stack is purely linear
• Displays – links to lexically enclosing scopes– links for dynamic control
• Exceptions– link to enclosing exception handler– links for dynamic control
display
enclosinghandler
April 12, 2000
David Walker, Cornell University 35
Displays
sp : ptr(lex1), display : ptr(display){lex1 <...,ptr(lex1caller)>} {lex2 <...,ptr(lex2caller)>} {display <ptr(lex1),ptr(lex2)>}
displaylex1
lex1caller
lex2
lex2caller
sp
April 12, 2000
David Walker, Cornell University 36
So Far• Alias tracking to a fixed depth
• Roughly corresponds to k-limited analyses• No way to specify repeated patterns
k = 2
April 12, 2000
David Walker, Cornell University 37
Outline
• Alias types [with Fred Smith, Greg Morrisett]
– The basics: concrete store types • Types for describing store shape• Type checking
– Abstraction mechanisms• Polymorphic, Existential & Recursive types
• Wrap-up– Implementation & research directions
April 12, 2000
David Walker, Cornell University 38
Existential Types• Existential Types
– hide object names so they can only be referenced locally
1
3- 2 only accessible through 1
pack
1 32
2
April 12, 2000
David Walker, Cornell University 39
Existential Introduction
{1 <ptr(2)>} {2 2} ...
top-level name & storage reference to 2 in location 1
1 2
...
April 12, 2000
David Walker, Cornell University 40
Existential Introduction
{1 <ptr(2)>} {2 2} ...
{1 [2 ]. {2 2 } . <ptr(2)> } ...
pack
hide name local storage the object in location 1
top-level name & storage
April 12, 2000
David Walker, Cornell University 41
Example
• Alternatives in a sum type may encapsulate data structures
{ 1 < > + [].{ <char> }.<int, ptr()> }
or 2
‘c’
1:
April 12, 2000
David Walker, Cornell University 42
Recursive Types
• Recursive types describe repeated patterns in the store .– standard roll/unroll coercions witness the
isomorphism
April 12, 2000
David Walker, Cornell University 43
Linear Lists
• Interior nodes can only be accessed through predecessors
{ 1 list . <> + [] . { list } . < int,ptr() > }
2 7 91:
null hidden tail heador
April 12, 2000
David Walker, Cornell University 44
In-place Append
2 71: 22:
2 71: 22:3
2 71: 3
{ 1 list } { 2 list }
{ 1 <int,ptr(next)> } { next list } { 2 list }
22:
{1 <int,ptr(next)>} {next <int,ptr(next’)>} {next’ list} {2 list}
3
April 12, 2000
David Walker, Cornell University 45
Append Invariant
21: 22:3
start : ptr(1), next : ptr(next), second : ptr(2)
{ next <int,ptr(end)> } { end list } { 2 list }
next end
start next
...
second
...
April 12, 2000
David Walker, Cornell University 46
In-place Append
2 71: 23
2 71: 3
{ 1 list }
2
... {next <int,ptr(next’)>} { next’ list}
... {next <int,ptr(next’)>} {next’ <int,ptr(2)>} {2 list}
2 71: 23
April 12, 2000
David Walker, Cornell University 47
Trees
{ tree.<> + [1,2].{1 tree}{2 tree}.<ptr(1),ptr(2)>}
:
:
{ dag.<> + [1].{1 dag}.<ptr(1),ptr(1)>}
April 12, 2000
David Walker, Cornell University 48
Other Possibilities
{ 1 clist . <ptr(1)> + [] . { clist } . < int,ptr() > }
2 7 91:
– queues– doubly-linked lists, trees with parent pointers
• require parametric recursive types– destination-passing style [Wadler,Larus,Cheng&Okasaki,Minamide]
– link-reversal algorithms [Deutsche&Schorr&Waite,Sobel&Friedman]
– circular lists:
April 12, 2000
David Walker, Cornell University 49
Limitations• All (useable) access paths must be known
statically• A tree with leaves linked in a list
– can be described but not used– how do you unfold the interior nodes of an
arbitrary tree when traversing the list?
...
April 12, 2000
David Walker, Cornell University 50
Outline
• Alias types [with Fred Smith, Greg Morrisett]
– The basics: concrete store types • Types for describing store shape• Type checking
– Abstraction mechanisms• Polymorphic, Existential & Recursive types
• Wrap-up– Implementation & research directions
April 12, 2000
David Walker, Cornell University 51
Implementation
• Currently in Typed Assembly Language:– Initialization of data structures– Run-time code generation
• code templates are copied into buffers, changing buffer type
– Alias tracking ensures consistency in the presence of operations that alter object type
– Intuitionistic extension• must-alias information, limited reuse
April 12, 2000
David Walker, Cornell University 52
Research Directions
• Language design– Source language support for safe, explicit MM– Application domains
• embedded, real-time systems
– Platforms: Popcorn Cyclone ?? • Popcorn: safe C + polymorphism, exceptions, ML data
types & pattern matching• Cyclone: gives programmers control over data layout• ??: gives programmers control over MM
April 12, 2000
David Walker, Cornell University 53
Research Directions• Further exploration of MM invariants:
– A single region of memory stores multiple objects [Tofte&Talpin]
– Region deallocation frees all objects in that region simultaneously
Aliasing
First-class
Reuse
•
Regions
Aliasing
First-class
Reuse
•
Objects in Regions
April 12, 2000
David Walker, Cornell University 54
Summary
• Low-level languages require operations for explicit memory reuse
• Types ensure safety by encoding rich memory management invariants
• Reading: – esop '00, http://www.cs.cornell.edu/talc
top related