alias types

54
Alias Types David Walker Cornell University What do you want to type check today?

Upload: amir-bryan

Post on 30-Dec-2015

70 views

Category:

Documents


1 download

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 Presentation

TRANSCRIPT

Page 1: Alias Types

Alias Types

David Walker

Cornell University

What do you want to type check today?

Page 2: Alias Types

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

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

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

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

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

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

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

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

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

April 12, 2000

David Walker, Cornell University 11

Alias Types

• Unlimited reuse• First-class• Some aliasing

Aliasing

First-class

Reuse

Page 12: Alias Types

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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