Monadic and Substructural Type Systems for Region-based Memory Management

1. Monadic and SubstructuralType Systems for Region-based Memory Management Matthew Fluet Cornell University

2. The Problem with Resources • Resources in a program are essential • file handles, DB connections, locks, memory, …

3. The Problem with Resources • Resources in a program are essential • file handles, DB connections, locks, memory, … • Resources need to be managed • state of a resource changes over time • using a resource in an incorrect state is WRONG

4. A Solution with Type Systems • Static type systems for programming languages(Java, C#, Standard ML) • well-typed programs don’t go WRONG

5. A Solution with Type Systems • Static type systems for programming languages(Java, C#, Standard ML) • well-typed programs don’t go WRONG • While today’s type systems are effective,they have limitations: • limited notion of WRONG • cannot express some resource-conscious programs

6. Memory Management • One of the most difficult resources to handle • Dynamic allocation and deallocation of data

7. Memory Management • One of the most difficult resources to handle • Dynamic allocation and deallocation of data • programs acquire and release memory as needed

8. Memory Management • Dynamic allocation and deallocation of data • Range of schemes for managing memory

9. Memory Management • Dynamic allocation and deallocation of data • Range of schemes for managing memory • malloc/free • explicit and efficient, but tedious and error prone

10. Memory Management • Dynamic allocation and deallocation of data • Range of schemes for managing memory • malloc/free • explicit and efficient, but tedious and error prone • garbage collection • convenient and safe, but carries overheads

11. Memory Management • Dynamic allocation and deallocation of data • Range of schemes for managing memory • malloc/free • explicit and efficient, but tedious and error prone • garbage collection • convenient and safe, but carries overheads • region-based memory management

12. Region-based Memory Management • A region (denoted by r, r, …) is a collectionof allocated data objects r1 r2

13. Region-based Memory Management • Arbitrary intra- and inter-region references • data objects in one region may have pointersto data objects in the same region and in other regions r1 r2

14. Region-based Memory Management • A program creates and destroys regions to acquire and release memory r1 r2

15. Region-based Memory Management • Creating a region yields an empty region r1 r2 r3

16. Region-based Memory Management • Data objects may be allocated in and read from a region r1 r2 r3

17. Region-based Memory Management • Destroying a region deallocates all objects in the region r1 r3

18. Region-based Memory Management • Destroying a region deallocates all objects in the region Existence of these pointers is O.K. Dereferencing these pointers is WRONG. r1 r3

19. Region-based Memory Management • Advantages • Disadvantages

20. Region-based Memory Management • Advantages • efficient implementations of mem. mgmt. operations • supports bulk deallocation of data objects • allows dangling pointers • Disadvantages

21. Region-based Memory Management • Advantages • efficient implementations of mem. mgmt. operations • supports bulk deallocation of data objects • allows dangling pointers • Disadvantages • allows various WRONG behaviors • dereferencing dangling pointers • allocating in destroyed regions • destroying region more than once

22. A Solution with Type Systems • Static type systems for programming languages(Java, C#, Standard ML) • well-typed programs don’t go WRONG • well-typed programs are region safe

23. A Solution with Type Systems • Static type systems for programming languages(Java, C#, Standard ML) • well-typed programs don’t go WRONG • well-typed programs are region safe • Previous work: type-and-effect systems

24. A Solution with Type Systems • Static type systems for programming languages(Java, C#, Standard ML) • well-typed programs don’t go WRONG • well-typed programs are region safe • Previous work: type-and-effect systems • complicated, for programmer and language designer • limited expressiveness, nested regions only

25. Type Systems for Region-based Memory Management • I have developed type systems for managing and enforcing the correct usage of regions • monadic type system • substructural type system • These type systems • are simpler than previous work • are more expressive than previous work • unify seemingly different language features

26. Type Systems for Region-based Memory Management • Type-and-effect system • effects pervasive in type system • complicated proof of soundness • Monadic type system • exploit parametric polymorphism (System F) • simple type system; well-understood theory • Substructural type system • exploit linearity to control access to region • supports richer programming idioms

27. Type-and-Effect Systems • Provide core mechanisms to describe computational effects of a program • Type: what the expression computes • Effect: how the expression computes • Languages • Lucassen-Gifford-Jouvelot: FX-89, FX-91 • Tofte-Talpin: region calculus, MLKit

28. Type-and-Effect Systems • Provide core mechanisms to describe computational effects of a program • Type: what the expression computes • Effect: how the expression computes • Languages • Lucassen-Gifford-Jouvelot: FX-89, FX-91 • Tofte-Talpin: region calculus, MLKit

29. Type-and-Effect System for Regions • refrt • object of type t allocated in region r;newRef, readRef, writeRef, … • hndr • handle for region r;the run-time value for allocating in a region

30. Type-and-Effect System for Regions • Regions are created and destroyed with syntax: letregion r, h in{ … } • Region is created at the start of scope and destroyed at the end of scope

31. Type-and-Effect System for Regions • Regions have nested lifetimes letregion r1, h1in{ letregion r2, h2in{ … } }

32. Type-and-Effect System for Regions letregion r1, h1in{ letregion r2, h2in{ … x = newRef (h2,“a”) … … } … readRef x … } r0

33. Type-and-Effect System for Regions letregion r1, h1in{ letregion r2, h2in{ … x = newRef (h2,“a”) … … } … readRef x … } r1 r0

34. Type-and-Effect System for Regions letregion r1, h1in{ letregion r2, h2in{ … x = newRef (h2,“a”) … … } … readRef x … } r2 r1 r0

35. Type-and-Effect System for Regions letregion r1, h1in{ letregion r2, h2in{ … x = newRef (h2,“a”) … … } … readRef x … }  x a “a” r2 r1 r0

36. Type-and-Effect System for Regions letregion r1, h1in{ letregion r2, h2in{ … x = newRef (h2,“a”) … … } … readRef x … } x a “a” r2 r1 r0

37. Type-and-Effect System for Regions letregion r1, h1in{ letregion r2, h2in{ … x = newRef (h2,“a”) … … } … readRef x … } r1 r0

38. Type-and-Effect System for Regions letregion r1, h1in{ letregion r2, h2in{ … x = newRef (h2,“a”) … … } … readRef x … } r1  r0

39. Type-and-Effect System for Regions letregion r1, h1in{ letregion r2, h2in{ … x = newRef (h2,“a”) … … f = (lz. … readRef x …) … } … f 2 … } r1  r0

40. Type-and-Effect System for Regions • Type-and-effect system ensures safety • Track the set f of regions used by an expression: G` e : t, f • Function types include a latent effect: t1!t2 f

41. Type-and-Effect System for Regions • Typing rule for letregion syntax: G,r,h:hndr` e : t, fr∉ frv(G,t) G`letregion r,h in { e } : t, f \ {r}

42. Type-and-Effect System for Regions • Typing rule for function application: G` e : t’ !t, fG` e’ : t’, f’ G` e e’ : t, f[f’ [ff • Type of ref operations: newRef :: 8r.8a. (hndr£a) !refra readRef :: 8r.8a. refra!a ff {r} {r}

43. Type-and-Effect System for Regions letregion r1, h1in{ letregion r2, h2in{ … x = newRef h2 “a” … … } … readRef x … } {} {r1} {r1,r2} {r1,r2} {r1,r2} {r1,r2} {r1} {} r22 {r1,r2} r22 {r1} 

44. Type-and-Effect System for Regions letregion r1, h1in{ letregion r2, h2in{ … x = newRef h2 “a” … … f = (lz. … readRef x …) … } … f 2 … } {} {r1} {r1,r2} {r1,r2} {r1,r2} {r1,r2} {r1} {} r22 {r1,r2} r22 {r1} 

45. Type-and-Effect System for Regions • Type-and-effect system ensures safety,but, adds complications: • Typing rule for letregion syntax is quite subtle(interplay of dangling pointers and effects) • [Tofte & Talpin ’94],[Crary et.al. ’99],[Banerjee et.al. ’99],[Helsen & Thiemann ’00],[Calcagno ’01],[Grossman et.al. ’01],[Calcagno et.al. ’02],[Henglein et.al. ’05],[Ganz ’05] • Effects are pervasive in typing rules • Effect weakening and region subtyping • Cyclone, [Grossman et.al. ’01] • Effects correspond to sets of region names (term equality no longer suffices for type checking)

46. Type-and-Effect System for Regions • Type-and-effect system ensures safety,but, adds complications: • Typing rule for letregion syntax is quite subtle(interplay of dangling pointers and effects) • [Tofte & Talpin ’94],[Crary et.al. ’99],[Banerjee et.al. ’99],[Helsen & Thiemann ’00], [Calcagno ’01],[Grossman et.al. ’01],[Calcagno et.al. ’02],[Henglein et.al. ’05],[Ganz ’05] • Effects are pervasive in typing rules • Effect weakening and region subtyping • Cyclone, [Grossman et.al. ’01] • Effects correspond to sets of region names (term equality no longer suffices for type checking)

47. Type-and-Effect System for Regions • Type-and-effect system ensures safety,but, adds complications: • Typing rule for letregion syntax is quite subtle(interplay of dangling pointers and effects) • [Tofte & Talpin ’94],[Crary et.al. ’99],[Banerjee et.al. ’99],[Helsen & Thiemann ’00],[Calcagno ’01],[Grossman et.al. ’01],[Calcagno et.al. ’02],[Henglein et.al. ’05],[Ganz ’05] • Effects are pervasive in typing rules • Effect weakening and region subtyping • Cyclone, [Grossman et.al. ’01] • Effects correspond to sets of region names (term equality no longer suffices for type checking)

48. Type-and-Effect System for Regions • Type-and-effect system ensures safety,but, adds complications: • Typing rule for letregion syntax is quite subtle(interplay of dangling pointers and effects) • [Tofte & Talpin ’94],[Crary et.al. ’99],[Banerjee et.al. ’99],[Helsen & Thiemann ’00],[Calcagno ’01],[Grossman et.al. ’01],[Calcagno et.al. ’02],[Henglein et.al. ’05],[Ganz ’05] • Effects are pervasive in typing rules • Effect weakening and region subtyping • [Grossman et.al. ’01] • Effects correspond to sets of region names (term equality no longer suffices for type checking) Programming with and proving soundness of type-and-effect systems is challenging.

49. Type-and-Effect System for Regions • Type-and-effect system ensures safety,but, adds complications: • Typing rule for letregion syntax is quite subtle(interplay of dangling pointers and effects) • [Tofte & Talpin ’94],[Crary et.al. ’99],[Banerjee et.al. ’99],[Helsen & Thiemann ’00],[Calcagno ’01],[Grossman et.al. ’01],[Calcagno et.al. ’02],[Henglein et.al. ’05],[Ganz ’05] • Effects are pervasive in typing rules • Effect weakening and region subtyping • [Grossman et.al. ’01] • Effects correspond to sets of names (term equality no longer suffices for type checking) Is there a simpler type system that provides the same safety and expressiveness?

50. Monadic Type System for Regions • Exploit parametric polymorphism (System F)and monadic encapsulation • Key insights: • Effects map to an indexed monadic type • Effect weakening and membership witnessed by types • Sufficient for encoding type-and-effect systems