1 / 54

Alias Types

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.

amir-bryan
Download Presentation

Alias Types

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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 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 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 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 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 x x x free(x) let y = <x.x> 3 3 free_list y x.x 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 David Walker, Cornell University

  8. ML Refs Aliasing • • 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 First-class Reuse David Walker, Cornell University

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

  10. Linear Typing Aliasing • Immediate reuse • First-class • No aliasing • one reference to an object of linear type First-class • Reuse David Walker, Cornell University

  11. Alias Types Aliasing • Unlimited reuse • First-class • Some aliasing • First-class Reuse 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 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, ... 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] 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 x' x x : int  (int  int) 5 7 2 z 5 7 x : int  (int  int) let y,z = x in ... y : int, z : (int  int) y = 2 x is implicitly recycled: 2 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 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 <int,int> address memory/object contents David Walker, Cornell University

  18. Store Types • Store types • Store type composition {l1 <int,int>} l1: 4 7 {l1 <int,int>}  {l2 <int,int>}  {l3 <int,int>} l1: 4 7 l2: 1 2 l3: 9 8 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>}  {l2 <char>} = {l2 <char>}  {l1 <int>} {l1 <int,int>}  {l1 <int,int>}  {l1 <int,int>} 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 l1: y 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)> } x 4 5 7 'a' y 4 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' }  ... David Walker, Cornell University

  23. Example • Initializing data structures: x ? ? { 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 3 ‘a’ David Walker, Cornell University

  24. Example • Use of a pointer requires proper store type: x 4 3 • { 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 • .... x 4 3 z x ? z 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 • ... 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 David Walker, Cornell University

  27. Location Polymorphism deref: { 0x12  <int> }.ptr(0x12)  { 0x12  <int> }.int • Only concrete location 0x12 can be dereferenced • Add location polymorphism: • The dependence between pointer and memory block is preserved deref: [1].{ 1 <int> }.ptr(1)  { 1 <int> }.int David Walker, Cornell University

  28. Example deref: [1].{ 1 <int> }.ptr(1)  { 1 <int> }.int • From now on, I will stop mentioning concrete locations  let , x = new(1) in {  <Top> }, x : ptr() x.1 := 3; {  <int> }, x : ptr() let y = deref [] (x) in {  <int> }, x : ptr(), y : int X 0x12: 3 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>} David Walker, Cornell University

  30. Subtyping? deref: [1].{ 1 <int> }.ptr(1)  { 1 <int> }.int • Subtyping (weakening) makes store components unusable: {  <int> }  { ' <int> } {  <int> } let _ = deref [] (x) in {  <int> } % ' inaccessible 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 David Walker, Cornell University

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

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

  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 David Walker, Cornell University

  35. Displays sp display lex1 lex1caller lex2 lex2caller sp : ptr(lex1), display : ptr(display) {lex1  <...,ptr(lex1caller)>}  {lex2 <...,ptr(lex2caller)>}  {display <ptr(lex1),ptr(lex2)>}   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 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 David Walker, Cornell University

  38. Existential Types • Existential Types • hide object names so they can only be referenced locally 1 2 3 pack 3 2 - 2 only accessible through 1 1 David Walker, Cornell University

  39. Existential Introduction reference to 2 in location 1 top-level name & storage {1 <ptr(2)>}  {22}  ... 1 2 ... David Walker, Cornell University

  40. Existential Introduction top-level name & storage {1 <ptr(2)>}  {22}  ... pack {1[2 ]. {22 }. <ptr(2)> }  ... the object in location 1 hide name local storage David Walker, Cornell University

  41. Example • Alternatives in a sum type may encapsulate data structures { 1 < > + [].{<char> }.<int, ptr()> } 1: or 2 ‘c’ David Walker, Cornell University

  42. Recursive Types • Recursive types describe repeated patterns in the store • . • standard roll/unroll coercions witness the isomorphism David Walker, Cornell University

  43. Linear Lists 1: 2 7 9 • Interior nodes can only be accessed through predecessors { 1 list . <> + [] . {  list } . < int,ptr() > } null or hidden tail head David Walker, Cornell University

  44. In-place Append { 1 list }  { 2 list } 1: 2 7 3 2: 2 { 1<int,ptr(next)> } { next list }  { 2 list } 1: 2 7 3 2: 2 {1<int,ptr(next)>} {next<int,ptr(next’)>}  {next’ list}  {2 list} 1: 2 7 3 2: 2 David Walker, Cornell University

  45. Append Invariant start next second ... ... 1: 2 3 2: 2  next end start : ptr(1), next : ptr(next), second : ptr(2)  { next<int,ptr(end)> } { end list }  { 2 list } David Walker, Cornell University

  46. In-place Append ...  {next<int,ptr(next’)>}  {next’ <int,ptr(2)>}  {2 list} 1: 2 7 3 2 ...  {next <int,ptr(next’)>}  { next’ list} 1: 2 7 3 2 { 1 list } 1: 2 7 3 2 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)>} David Walker, Cornell University

  48. Other Possibilities • circular lists: • 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] 1: 2 7 9 { 1 clist . <ptr(1)> + [] . {  clist } . < int,ptr() > } 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? ... 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 David Walker, Cornell University

More Related