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

2. April 12, 2000David Walker, Cornell University2 Types in Compilation Terms Types Typed Source Typed Intermediate Typed Target Type-preserving compilers [Java,Til(t),Touchstone,Popcorn] –produce certified code –improve reliability & security

3. April 12, 2000David Walker, Cornell University3 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. April 12, 2000David Walker, Cornell University4 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. April 12, 2000David Walker, Cornell University5 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. April 12, 2000David Walker, Cornell University6 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 y x x.x

7. April 12, 2000David Walker, Cornell University7 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. April 12, 2000David Walker, Cornell University8 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

9. April 12, 2000David Walker, Cornell University9 Stack Allocation Unlimited reuse Some aliasing Not first-class Examples –algol, stack-based (typed) assembly language Aliasing First-class Reuse

10. April 12, 2000David Walker, Cornell University10 Linear Typing Immediate reuse First-class No aliasing –one reference to an object of linear type Aliasing First-class Reuse

11. April 12, 2000David Walker, Cornell University11 Alias Types Unlimited reuse First-class Some aliasing Aliasing First-class Reuse

12. April 12, 2000David Walker, Cornell University12 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. April 12, 2000David Walker, Cornell University13 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. April 12, 2000David Walker, Cornell University14 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. April 12, 2000David Walker, Cornell University15 Linear Types Linear types ensure there is one access path to any memory object A single-use constraint preserves the invariant 2 57 x 57 z y = 2 2x is implicitly recycled: x' x : int  (int  int) let y,z = x in... y : int, z : (int  int)

16. April 12, 2000David Walker, Cornell University16 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. April 12, 2000David Walker, Cornell University17 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 addressmemory/object contents

18. April 12, 2000David Walker, Cornell University18 Store Types Store types Store type composition 4 l1:l1: 7 {l 1  } 4 l1:l1: 7 {l 1  }  {l 2  }  {l 3  } 1 l2:l2: 2 9 l3:l3: 8

19. April 12, 2000David Walker, Cornell University19 Store Types Store component types are unordered: No aliasing/duplication of store types –one type associated with each address –no contraction rule {l 1  }  {l 1  }  {l 1  } {l 1  }  {l 2  } = {l 2  }  {l 1  }

20. April 12, 2000David Walker, Cornell University20 Aliasing Pointers have singleton type –x : ptr(l 1 ) –"x points to the object at address l 1 " –aliases == pointers to objects with the same name –eg: x : ptr(l 1 ), y : ptr(l 1 ) x y l1:l1:

21. April 12, 2000David Walker, Cornell University21 Aliasing A dag: { l 1  }  { l 2  }  { l 3  } x : ptr(l 1 ), y : ptr(l 2 ) A cycle: { l 1  } 574 x y 'a' 4

22. April 12, 2000David Walker, Cornell University22 Type Checking Store types vary between program points: { l 1   1 }  { l 2   2 } ... instruction { l 1   1 ' }  { l 2   2 } ... instruction { l 1   1 ' }  { l 2   2 ' } ...

23. April 12, 2000David Walker, Cornell University23 Example Initializing data structures: { l  }, x : ptr(l) x.1 := 3; { l  }, x : ptr(l) x.2 := 'a'; { l  }, x : ptr(l) ? x ? 3 x ‘a’

24. April 12, 2000David Walker, Cornell University24 Example Use of a pointer requires proper store type: { l 1  }, x:ptr(l 1 ) let z = x in { l 1  }, x:ptr(l 1 ), z:ptr(l 1 ) free (z); , x:ptr(l 1 ), z:ptr(l 1 ) let w = x.1 in % Wrong: l 1 not present in store.... 4 x 3 ? 4 x 3 z x z

25. April 12, 2000David Walker, Cornell University25 Functions Function types specify input & output store: A call site: Technical note: calculus formalized in continuation-passing style f : { l 1  }.  1  { l 1  }.  2 { l 1  }, x :  1 let y = f (x) in { l 1  }, x :  1,y :  2...

26. April 12, 2000David Walker, Cornell University26 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. April 12, 2000David Walker, Cornell University27 Location Polymorphism –Only concrete location 0x12 can be dereferenced –Add location polymorphism: –The dependence between pointer and memory block is preserved deref: { 0x12  }.ptr(0x12)  { 0x12  }.int deref:  [  1 ].{  1  }.ptr(  1 )  {  1  }.int

28. April 12, 2000David Walker, Cornell University28 Example deref:  [  1 ].{  1  }.ptr(  1 )  {  1  }.int  let , x = new(1) in {   }, x : ptr(  ) x.1 := 3; {   }, x : ptr(  ) let y = deref [  ] (x) in {   }, x : ptr(  ), y : int 0x12: –From now on, I will stop mentioning concrete locations 3 X

29. April 12, 2000David Walker, Cornell University29 Another Difficulty Currently, deref can only be used in a store with one reference: deref:  [  1 ].{  1  }.ptr(  1 )  {  1  }.int let , x = new(1) in x.1 := 3; let  ', y = new(1) in y.1 := 7; {   }  {  '  } let _ = deref [  ] (x)... % {   }  {  '  }  {   }

30. April 12, 2000David Walker, Cornell University30 Subtyping? –Subtyping (weakening) makes store components unusable: deref:  [  1 ].{  1  }.ptr(  1 )  {  1  }.int {   }  {  '  }  {   } let _ = deref [  ] (x) in {   } %  ' inaccessible

31. April 12, 2000David Walker, Cornell University31 Store Polymorphism –Store polymorphism hides store size and shape from callee & preserves it across the call deref:  [ ,  1 ].   {  1  }.ptr(  1 )    {  1  }.int store preserved across the call

32. April 12, 2000David Walker, Cornell University32 Example x: ptr(  ), y: ptr(  '), {   }  {  '  } let _ = deref [{  '  },  ] (x) in % OK {   }  {  '  } let _ = deref [{   },  '] (y) in % OK {   }  {  '  } deref:  [ ,  1 ].   {  1  }.ptr(  1 )    {  1  }.int –deref may be called with different references and preserves the store at each step:

33. April 12, 2000David Walker, Cornell University33 Example: A stack foo:  [ ,  sp,  caller ]. {  sp  }  . ptr(  sp ) .... stack frame stack pointer pointer to caller's frame rest of the stack   sp :  caller : function argument on stack O'Hearn & Reynolds Stack-based TAL

34. April 12, 2000David Walker, Cornell University34 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 enclosing handler

35. April 12, 2000David Walker, Cornell University35 Displays sp : ptr(  lex1 ), display : ptr(  display ) {  lex1  }  {  lex2  }  {  display  }   display  lex1  lex1caller  lex2  lex2caller sp

36. April 12, 2000David Walker, Cornell University36 So Far Alias tracking to a fixed depth Roughly corresponds to k-limited analyses No way to specify repeated patterns  k = 2

37. April 12, 2000David Walker, Cornell University37 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. April 12, 2000David Walker, Cornell University38 Existential Types –hide object names so they can only be referenced locally 11 33 -  2 only accessible through  1 pack 11 33 22 22

39. April 12, 2000David Walker, Cornell University39 Existential Introduction {  1  }  {  2   2 } ... top-level name & storage reference to  2 in location  1 11 22...

40. April 12, 2000David Walker, Cornell University40 Existential Introduction {  1  }  {  2   2 } ... {  1   [  2 ]. {  2   2 }. } ... pack hide namelocal storage the object in location  1 top-level name & storage

41. April 12, 2000David Walker, Cornell University41 Example Alternatives in a sum type may encapsulate data structures {  1  +  [  ].{   }. } or 2 ‘c’ 1:1:

42. April 12, 2000David Walker, Cornell University42 Recursive Types Recursive types describe repeated patterns in the store – .  –standard roll/unroll coercions witness the isomorphism

43. April 12, 2000David Walker, Cornell University43 Linear Lists Interior nodes can only be accessed through predecessors {  1   list. <> +  [  ]. {   list }. } 279 1:1: nullhidden tailheador

44. April 12, 2000David Walker, Cornell University44 In-place Append 27 1:1: 2 2:2: 27 1:1: 2 2:2: 3 27 1:1: 3 {  1  list }  {  2  list } {  1  }  {  next  list }  {  2  list } 2 2:2: {  1  }  {  next  }  {  next’  list}  {  2  list} 3

45. April 12, 2000David Walker, Cornell University45 Append Invariant 2 1:1: 2 2:2: 3 start : ptr(  1 ), next : ptr(  next ), second : ptr(  2 )   {  next  }  {  end  list }  {  2  list }  next  end startnext... second...

46. April 12, 2000David Walker, Cornell University46 In-place Append 27 1:1: 23 27 1:1: 3 {  1  list } 2...  {  next  }  {  next’  list}...  {  next  }  {  next’  }  {  2  list} 27 1:1: 23

47. April 12, 2000David Walker, Cornell University47 Trees {    tree.<> +  [  1,  2 ].{  1  tree}  {  2  tree}. } :: :: {    dag.<> +  [  1 ].{  1  dag}. }

48. April 12, 2000David Walker, Cornell University48 Other Possibilities {  1   clist. +  [  ]. {   clist }. } 279 1:1: –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:

49. April 12, 2000David Walker, Cornell University49 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. April 12, 2000David Walker, Cornell University50 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. April 12, 2000David Walker, Cornell University51 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. April 12, 2000David Walker, Cornell University52 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. April 12, 2000David Walker, Cornell University53 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

54. April 12, 2000David Walker, Cornell University54 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