alias types

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