Title: Alias Types
1Alias Types
What do you want to type check today?
- David Walker
- Cornell University
2Types in Compilation
Types
Terms
Typed Source
Typed Intermediate
Typed Target
- Type-preserving compilers Java,Til(t),Touchstone,
Popcorn - produce certified code
- improve reliability security
3High-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
4Memory 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
5Goals
- Study memory management invariants
- Make invariants explicit in a type system
- provide compiler writers, systems hackers with
flexibility safety - Today
- one particular type system
6Hazards
- When memory is recycled, it may be used to store
objects of different types - x must not be used an integer reference
x
x
x
free(x)
let y lt?x.xgt
3
3
free_list
y
?x.x
7MM 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
8ML Refs
Aliasing
First-class
Reuse
- 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
9Stack Allocation
Aliasing
First-class
Reuse
- Unlimited reuse
- Some aliasing
- Not first-class
- Examples
- algol, stack-based (typed) assembly language
10Linear Typing
Aliasing
- Immediate reuse
- First-class
- No aliasing
- one reference to an object of linear type
First-class
Reuse
11Alias Types
Aliasing
First-class
- Unlimited reuse
- First-class
- Some aliasing
Reuse
12Outline
- 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
13Alias 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, ...
14Our 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
15Linear Types
- Linear types ensure there is one access path to
any memory object - A single-use constraint preserves the invariant
x'
x
x int ? (int ? int)
5
7
2
z
5
7
y 2
x int ? (int ? int) let y,z x in ... y int,
z (int ? int)
2
x is implicitly recycled
16Aliasing
- 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
17Alias 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
ltint,intgt
address
memory/object contents
18Store Types
- Store types
- Store type composition
l1 ? ltint,intgt
4
l1
7
4
l1
7
l1 ? ltint,intgt ? l2 ? ltint,intgt ? l3 ?
ltint,intgt
1
l2
2
9
l3
8
19Store Types
- Store component types are unordered
- No aliasing/duplication of store types
- one type associated with each address
- no contraction rule
l1 ? ltintgt ? l2 ? ltchargt l2 ? ltchargt
? l1 ? ltintgt
l1 ? ltint,intgt ? l1 ? ltint,intgt ? l1 ?
ltint,intgt
20Aliasing
- 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
l1
y
21Aliasing
- A dag
- l1 ? ltint,ptr(l3)gt ?
- l2 ? ltchar,ptr(l3)gt ?
- l3 ? ltint,intgt
- x ptr(l1), y ptr(l2)
- A cycle
- l1 ? ltint,ptr(l1)gt
5
7
4
x
'a'
y
4
22Type Checking
- Store types vary between program points
l1 ? ?1 ? l2 ? ?2 ? ... instruction l1
? ?1' ? l2 ? ?2 ? ... instruction l1 ?
?1' ? l2 ? ?2' ? ...
23Example
- Initializing data structures
?
x
?
l ? ltTop,Topgt , x ptr(l) x.1 3 l ?
ltint,Topgt , x ptr(l) x.2 'a' l ?
ltint,chargt , x ptr(l)
3
x
a
24Example
- Use of a pointer requires proper store type
4
x
3
l1 ? ltint,intgt , xptr(l1) let z x in l1
? ltint,intgt , xptr(l1), zptr(l1) free
(z) ?, xptr(l1), zptr(l1) let w x.1 in
Wrong l1 not present in store ....
4
x
3
z
x
?
z
25Functions
- Function types specify input output store
- A call site
- Technical note calculus formalized in
continuation-passing style
f l1 ? ltint,intgt .?1 ? l1 ? ltchar,chargt
.?2
l1 ? ltint,intgt , x ?1 let y f (x) in l1
? ltchar,chargt , x ?1,y ?2 ...
26Outline
- 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
27Location Polymorphism
deref 0x12 ? ltintgt .ptr(0x12) ? 0x12 ?
ltintgt .int
-
- Only concrete location 0x12 can be dereferenced
- Add location polymorphism
- The dependence between pointer and memory block
is preserved
deref ??1. ?1 ? ltintgt .ptr(?1) ? ?1 ?
ltintgt .int
28Example
deref ??1. ?1 ? ltintgt .ptr(?1) ? ?1 ?
ltintgt .int
? let ?, x new(1) in ? ? ltTopgt , x ptr(?)
x.1 3 ? ? ltintgt , x ptr(?) let y
deref ? (x) in ? ? ltintgt , x ptr(?), y
int
X
0x12
3
- From now on, I will stop mentioning concrete
locations
29Another Difficulty
- Currently, deref can only be used in a store with
one reference
deref ??1. ?1 ? ltintgt .ptr(?1) ? ?1 ?
ltintgt .int
let ?, x new(1) in x.1 3 let ?', y
new(1) in y.1 7 ? ? ltintgt ? ?' ? ltintgt
let _ deref ? (x) ... ? ? ltintgt ? ?'
? ltintgt ? ? ? ltintgt
30Subtyping?
deref ??1. ?1 ? ltintgt .ptr(?1) ? ?1 ?
ltintgt .int
- Subtyping (weakening) makes store components
unusable
? ? ltintgt ? ?' ? ltintgt ? ? ? ltintgt
let _ deref ? (x) in ? ? ltintgt
?' inaccessible
31Store Polymorphism
- Store polymorphism hides store size and shape
from callee preserves it across the call
deref ??,?1. ? ? ?1 ? ltintgt .ptr(?1) ? ? ?
?1 ? ltintgt .int
store preserved across the call
32Example
deref ??,?1. ? ? ?1 ? ltintgt .ptr(?1) ? ? ?
?1 ? ltintgt .int
- deref may be called with different references and
preserves the store at each step
x ptr(?), y ptr(?'), ? ? ltintgt ? ?' ?
ltintgt let _ deref ?' ? ltintgt ,? (x) in
OK ? ? ltintgt ? ?' ?
ltintgt let _ deref ? ? ltintgt ,?' (y) in
OK ? ? ltintgt ? ?' ?
ltintgt
33Example A stack
rest of the stack
foo??,?sp,?caller. ?sp ? ltint,ptr(?caller)gt
? ? . ptr(?sp) ? ....
stack frame
stack pointer
pointer to caller's frame
function argument on stack
?sp
?caller
- O'Hearn Reynolds
- Stack-based TAL
?
34Aliasing
display
- 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
enclosing handler
35Displays
display
sp
?lex1
?lex1caller
?lex2
?lex2caller
sp ptr(?lex1), display ptr(?display) ?lex1
? lt...,ptr(?lex1caller)gt ? ?lex2 ?
lt...,ptr(?lex2caller)gt ? ?display ?
ltptr(?lex1),ptr(?lex2)gt ? ?
36So Far
- Alias tracking to a fixed depth
- Roughly corresponds to k-limited analyses
- No way to specify repeated patterns
?
k 2
37Outline
- 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
38Existential Types
- Existential Types
- hide object names so they can only be referenced
locally
?1
?3
?2
pack
?3
?2
- ?2 only accessible through ?1
?1
39Existential Introduction
reference to ?2 in location ?1
top-level name storage
?1 ? ltptr(?2)gt ?
?2 ? ?2 ? ...
?1
?2
...
40Existential Introduction
top-level name storage
?1 ? ltptr(?2)gt ?
?2 ? ?2 ? ...
pack
?1 ? ??2 . ?2 ? ?2 . ltptr(?2)gt
? ...
the object in location ?1
hide name
local storage
41Example
- Alternatives in a sum type may encapsulate data
structures
?1 ? lt gt ??.? ? ltchargt .ltint, ptr(?)gt
?1
or
2
c
42Recursive Types
- Recursive types describe repeated patterns in the
store - ??.?
- standard roll/unroll coercions witness the
isomorphism
43Linear Lists
2
7
9
?1
?1 ? ? list . ltgt ?? . ? ? list
. lt int,ptr(?) gt
null
hidden tail
head
or
- Interior nodes can only be accessed through
predecessors
44In-place Append
?1 ? list ? ?2 ? list
2
7
?1
2
?2
3
?1 ? ltint,ptr(?next)gt ? ?next ? list ?
?2 ? list
2
7
?1
2
?2
3
?1 ? ltint,ptr(?next)gt ? ?next ?
ltint,ptr(?next)gt ? ?next ? list ? ?2 ?
list
2
7
?1
3
2
?2
45Append Invariant
start
next
second
...
...
2
?1
2
?2
3
?
?next
?end
start ptr(?1), next ptr(?next),
second ptr(?2) ? ? ?next ? ltint,ptr(?end)gt
? ?end ? list ? ?2 ? list
46In-place Append
... ? ?next ? ltint,ptr(?next)gt ? ?next ?
ltint,ptr(?2)gt ? ?2 ? list
2
7
?1
3
2
... ? ?next ? ltint,ptr(?next)gt ? ?next ?
list
2
7
?1
2
3
?1 ? list
2
7
?1
2
3
47Trees
?
? ? ? tree.ltgt ??1,?2.?1 ? tree??2 ?
tree.ltptr(?1),ptr(?2)gt
?
? ? ? dag.ltgt ??1.?1 ? dag.ltptr(?1),ptr(?1)gt
48Other Possibilities
2
7
9
?1
?1 ? ? clist . ltptr(?1)gt ?? . ? ? clist
. lt int,ptr(?) gt
- queues
- doubly-linked lists, trees with parent pointers
- require parametric recursive types
- destination-passing style Wadler,Larus,ChengOkas
aki,Minamide - link-reversal algorithms DeutscheSchorrWaite,So
belFriedman
49Limitations
- 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?
...
50Outline
- 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
51Implementation
- 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
52Research 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
53Research Directions
- Further exploration of MM invariants
- A single region of memory stores multiple objects
TofteTalpin - Region deallocation frees all objects in that
region simultaneously
Regions
Objects in Regions
Aliasing
Aliasing
First-class
First-class
Reuse
Reuse
54Summary
- 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