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


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


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


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


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


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


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


Stack Allocation

• Unlimited reuse• Some aliasing• Not first-class• Examples

– algol, stack-based (typed) assembly language

Aliasing

First-class

Reuse

•

April 12, 2000


Linear Typing

• Immediate reuse • First-class• No aliasing

– one reference to an object of linear type

Aliasing

First-class

Reuse•

April 12, 2000


Alias Types

• Unlimited reuse• First-class• Some aliasing

Aliasing

First-class

Reuse

•

April 12, 2000


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


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


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


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


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


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


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


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


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


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


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


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


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


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


Outline





April 12, 2000


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


Example


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


Another Difficulty

• Currently, deref can only be used in a store with one reference:


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


Subtyping?

– Subtyping (weakening) makes store components unusable:


{ <int> } { ' <int> } { <int> }let _ = deref [] (x) in{ <int> } % ' inaccessible

April 12, 2000


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


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


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


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


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


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


Outline





April 12, 2000


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


Existential Introduction

{1 <ptr(2)>} {2 2} ...

top-level name & storage reference to 2 in location 1

1 2

...

April 12, 2000


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


Example

• Alternatives in a sum type may encapsulate data structures

{ 1 < > + [].{ <char> }.<int, ptr()> }

or 2

‘c’

1:

April 12, 2000


Recursive Types

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

isomorphism

April 12, 2000


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


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


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


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


Trees

{ tree.<> + [1,2].{1 tree}{2 tree}.<ptr(1),ptr(2)>}

:

:

{ dag.<> + [1].{1 dag}.<ptr(1),ptr(1)>}

April 12, 2000


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


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


Outline





April 12, 2000


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


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


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


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

Alias Types

Documents

Transcript of Alias Types