Alias Types

1
Alias Types
What do you want to type check today?

• David Walker
• Cornell University

2
Types in Compilation
Types
Terms
Typed Source
Typed Intermediate
Typed Target

• Type-preserving compilers Java,Til(t),Touchstone,
  Popcorn
• produce certified code
• improve reliability security

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

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

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

6
Hazards

• 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
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
8
ML 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

9
Stack Allocation
Aliasing

First-class
Reuse

• Unlimited reuse
• Some aliasing
• Not first-class
• Examples
• algol, stack-based (typed) assembly language

10
Linear Typing
Aliasing

• Immediate reuse
• First-class
• No aliasing
• one reference to an object of linear type

First-class

Reuse
11
Alias Types
Aliasing

First-class

• Unlimited reuse
• First-class
• Some aliasing

Reuse
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

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, ...

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

15
Linear 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
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

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
ltint,intgt
address
memory/object contents
18
Store 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
19
Store 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
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
l1
y
21
Aliasing

• 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
22
Type Checking

• Store types vary between program points

l1 ? ?1 ? l2 ? ?2 ? ... instruction l1
? ?1' ? l2 ? ?2 ? ... instruction l1 ?
?1' ? l2 ? ?2' ? ...
23
Example

• 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
24
Example

• 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
25
Functions

• 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 ...
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

27
Location 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
28
Example
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

29
Another 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
30
Subtyping?
deref ??1. ?1 ? ltintgt .ptr(?1) ? ?1 ?
ltintgt .int

• Subtyping (weakening) makes store components
  unusable

? ? ltintgt ? ?' ? ltintgt ? ? ? ltintgt
let _ deref ? (x) in ? ? ltintgt
?' inaccessible
31
Store 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
32
Example
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
33
Example 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

?
34
Aliasing
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
35
Displays
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 ? ?
36
So Far

• Alias tracking to a fixed depth
• Roughly corresponds to k-limited analyses
• No way to specify repeated patterns

?
k 2
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

38
Existential 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
39
Existential Introduction
reference to ?2 in location ?1
top-level name storage
?1 ? ltptr(?2)gt ?
?2 ? ?2 ? ...
?1
?2
...
40
Existential 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
41
Example

• Alternatives in a sum type may encapsulate data
  structures

?1 ? lt gt ??.? ? ltchargt .ltint, ptr(?)gt
?1
or
2
c
42
Recursive Types

• Recursive types describe repeated patterns in the
  store
• ??.?
• standard roll/unroll coercions witness the
  isomorphism

43
Linear 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

44
In-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
45
Append 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
46
In-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
47
Trees
?
? ? ? tree.ltgt ??1,?2.?1 ? tree??2 ?
tree.ltptr(?1),ptr(?2)gt
?
? ? ? dag.ltgt ??1.?1 ? dag.ltptr(?1),ptr(?1)gt

48
Other Possibilities

• circular lists

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

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?

...
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

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

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

53
Research 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
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