Alias Types - PowerPoint PPT Presentation

About This Presentation
Title:

Alias Types

Description:

Alias Types What do you want to type check today? David Walker Cornell University – PowerPoint PPT presentation

Number of Views:91
Avg rating:3.0/5.0
Slides: 55
Provided by: walk90
Learn more at: http://www.cs.cmu.edu
Category:
Tags: alias | basics | esop | types

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com