alias types
DESCRIPTION
Alias Types. What do you want to type check today?. David Walker Cornell University. Types in Compilation. Types. Terms. Type-preserving compilers [Java,Til(t),Touchstone,Popcorn] produce certified code improve reliability & security. Typed Source. Typed Intermediate. Typed Target. - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/1.jpg)
Alias Types
David Walker
Cornell University
What do you want to type check today?
![Page 2: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/2.jpg)
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
![Page 3: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/3.jpg)
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
![Page 4: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/4.jpg)
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
![Page 5: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/5.jpg)
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
![Page 6: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/6.jpg)
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
![Page 7: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/7.jpg)
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
![Page 8: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/8.jpg)
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
•
![Page 9: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/9.jpg)
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
•
![Page 10: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/10.jpg)
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•
![Page 11: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/11.jpg)
April 12, 2000
David Walker, Cornell University 11
Alias Types
• Unlimited reuse• First-class• Some aliasing
Aliasing
First-class
Reuse
•
![Page 12: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/12.jpg)
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
![Page 13: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/13.jpg)
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, ...
![Page 14: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/14.jpg)
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]
![Page 15: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/15.jpg)
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)
![Page 16: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/16.jpg)
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
![Page 17: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/17.jpg)
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>
![Page 18: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/18.jpg)
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
![Page 19: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/19.jpg)
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>}
![Page 20: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/20.jpg)
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:
![Page 21: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/21.jpg)
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
![Page 22: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/22.jpg)
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' } ...
![Page 23: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/23.jpg)
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’
![Page 24: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/24.jpg)
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
![Page 25: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/25.jpg)
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
...
![Page 26: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/26.jpg)
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
![Page 27: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/27.jpg)
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
![Page 28: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/28.jpg)
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
![Page 29: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/29.jpg)
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>}
![Page 30: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/30.jpg)
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
![Page 31: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/31.jpg)
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
![Page 32: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/32.jpg)
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:
![Page 33: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/33.jpg)
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
![Page 34: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/34.jpg)
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
![Page 35: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/35.jpg)
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
![Page 36: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/36.jpg)
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
![Page 37: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/37.jpg)
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
![Page 38: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/38.jpg)
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
![Page 39: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/39.jpg)
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
...
![Page 40: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/40.jpg)
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
![Page 41: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/41.jpg)
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:
![Page 42: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/42.jpg)
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
![Page 43: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/43.jpg)
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
![Page 44: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/44.jpg)
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
![Page 45: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/45.jpg)
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
...
![Page 46: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/46.jpg)
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
![Page 47: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/47.jpg)
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)>}
![Page 48: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/48.jpg)
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:
![Page 49: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/49.jpg)
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?
...
![Page 50: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/50.jpg)
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
![Page 51: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/51.jpg)
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
![Page 52: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/52.jpg)
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
![Page 53: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/53.jpg)
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
![Page 54: Alias Types](https://reader033.vdocuments.us/reader033/viewer/2022061612/56812c2f550346895d90b3d0/html5/thumbnails/54.jpg)
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