LaCasa: Lightweight Affinity and Object Capabilities in Scala

Transcript

1. LaCasa: Lightweight Affinity and Object Capabilities in Scala 1 Philipp

   Haller Northeastern University, USA September 29, 2016 KTH Royal Institute of Technology, Sweden

2. Concurrency is Difficult 2

3. Concurrency is Difficult Hazards: • Race conditions • Deadlocks •

   Livelocks • etc. 2

4. Concurrency is Difficult Hazards: • Race conditions • Deadlocks •

   Livelocks • etc. 2 Remedies?

5. Concurrency is Difficult Hazards: • Race conditions • Deadlocks •

   Livelocks • etc. 2 Monitors Futures, promises Actors CSP Join-calculus STM Async/await Reactive streams … Remedies?

6. Concurrency in Scala • Scala = “Scalable Language” • cf.

   Guy Steele. Growing a Language. OOPSLA ’98 keynote • Concurrency models as libraries • Reuse of compilers, debuggers, and IDEs • Flexible extension and adaptation 3

7. Concurrency in Scala • Scala = “Scalable Language” • cf.

   Guy Steele. Growing a Language. OOPSLA ’98 keynote • Concurrency models as libraries • Reuse of compilers, debuggers, and IDEs • Flexible extension and adaptation 3 Do not have to guess the answer to the question: Which concurrency model is going to “win”?

8. Background • Authored or co-authored: • Scala Actors (2006) •

   Scala Joins (2008) • Scala futures/promises (2012) • FlowPools (2012) • Scala Async (2013) • Contributions to Akka, Akka.js projects at Typesafe 4 Haller and Sommers Artima Press, 2012

9. Background • Authored or co-authored: • Scala Actors (2006) •

   Scala Joins (2008) • Scala futures/promises (2012) • FlowPools (2012) • Scala Async (2013) • Contributions to Akka, Akka.js projects at Typesafe 4 Haller and Sommers Artima Press, 2012 Production use at Twitter, The Guardian and others

10. Background • Authored or co-authored: • Scala Actors (2006) •

    Scala Joins (2008) • Scala futures/promises (2012) • FlowPools (2012) • Scala Async (2013) • Contributions to Akka, Akka.js projects at Typesafe 4 Haller and Sommers Artima Press, 2012 Production use at Twitter, The Guardian and others Production use at Morgan Stanley, Gawker and others

11. Background • Authored or co-authored: • Scala Actors (2006) •

    Scala Joins (2008) • Scala futures/promises (2012) • FlowPools (2012) • Scala Async (2013) • Contributions to Akka, Akka.js projects at Typesafe 4 Haller and Sommers Artima Press, 2012 Production use at Twitter, The Guardian and others Production use at Morgan Stanley, Gawker and others The programming-models-as-libraries approach has been successful in Scala!

12. Problem: Programming-models-as-libraries typically cannot prevent common concurrency hazards statically! 5

13. Example Image data 6

14. Example Image data apply filter 6

15. Example Image data apply filter 6

16. Example Image data apply filter Image processing pipeline: filter 1

    filter 2 6

17. Example Image data apply filter Image processing pipeline: filter 1

    filter 2 6 Pipeline stages run concurrently

18. Example: Implementation 7

19. Example: Implementation • Assumptions: • Image data large • Main

    memory expensive 7

20. Example: Implementation • Assumptions: • Image data large • Main

    memory expensive • Approach for high performance: • In-place update of image buffers • Pass mutable buffers by-reference 7

21. Example: Problem Easy to produce data races: 1. Stage 1

    sends a reference to a buffer to stage 2 2. Following the send, both stages have a reference to the same buffer 3. Stages can concurrently access the buffer 8

22. Preventing Data Races 9

23. Preventing Data Races • Approach: safe transfer of ownership 9

24. Preventing Data Races • Approach: safe transfer of ownership •

    Sending stage loses ownership 9

25. Preventing Data Races • Approach: safe transfer of ownership •

    Sending stage loses ownership • Compiler prevents sender from accessing objects that have been transferred 9

26. Preventing Data Races • Approach: safe transfer of ownership •

    Sending stage loses ownership • Compiler prevents sender from accessing objects that have been transferred • Advantages: 9

27. Preventing Data Races • Approach: safe transfer of ownership •

    Sending stage loses ownership • Compiler prevents sender from accessing objects that have been transferred • Advantages: • No run-time overhead 9

28. Preventing Data Races • Approach: safe transfer of ownership •

    Sending stage loses ownership • Compiler prevents sender from accessing objects that have been transferred • Advantages: • No run-time overhead • Safety does not compromise performance 9

29. Preventing Data Races • Approach: safe transfer of ownership •

    Sending stage loses ownership • Compiler prevents sender from accessing objects that have been transferred • Advantages: • No run-time overhead • Safety does not compromise performance • Errors caught at compile time 9

30. Ownership Transfer in Scala 10

31. Ownership Transfer in Scala • Enter LaCasa 10

32. Ownership Transfer in Scala • Enter LaCasa • LaCasa: Scala

    extension for affine references 10

33. Ownership Transfer in Scala • Enter LaCasa • LaCasa: Scala

    extension for affine references • “Transferable” references 10

34. Ownership Transfer in Scala • Enter LaCasa • LaCasa: Scala

    extension for affine references • “Transferable” references • At most one owner per transferable reference 10

35. Motivation 11

36. Motivation • Interesting applications of linearity/affinity/ ownership transfer 11

37. Motivation • Interesting applications of linearity/affinity/ ownership transfer • Data-race

    safety 11

38. Motivation • Interesting applications of linearity/affinity/ ownership transfer • Data-race

    safety • Safe memory management without GC 11

39. Motivation • Interesting applications of linearity/affinity/ ownership transfer • Data-race

    safety • Safe memory management without GC • Session types (with extensions) 11

40. Motivation • Interesting applications of linearity/affinity/ ownership transfer • Data-race

    safety • Safe memory management without GC • Session types (with extensions) • Scala for embedded real-time systems? 11

41. Motivation • Interesting applications of linearity/affinity/ ownership transfer • Data-race

    safety • Safe memory management without GC • Session types (with extensions) • Scala for embedded real-time systems? • No GC/run-time system 11

42. Isn’t it a Solved Problem? 12

43. Isn’t it a Solved Problem? • Adoption surprisingly challenging 12

44. Isn’t it a Solved Problem? • Adoption surprisingly challenging •

    Ownership not available in mainstream languages 12

45. Isn’t it a Solved Problem? • Adoption surprisingly challenging •

    Ownership not available in mainstream languages • Contender: Rust 12

46. Isn’t it a Solved Problem? • Adoption surprisingly challenging •

    Ownership not available in mainstream languages • Contender: Rust 12 What about existing languages?

47. Isn’t it a Solved Problem? • Adoption surprisingly challenging •

    Ownership not available in mainstream languages • Contender: Rust • Own system [1] influential, but: 12 [1] Haller and Odersky. Capabilities for uniqueness and borrowing. ECOOP ’10 What about existing languages?

48. Isn’t it a Solved Problem? • Adoption surprisingly challenging •

    Ownership not available in mainstream languages • Contender: Rust • Own system [1] influential, but: 12 [2] Gordon et al. Uniqueness and reference immutability for safe parallelism. OOPSLA ’12 [1] Haller and Odersky. Capabilities for uniqueness and borrowing. ECOOP ’10 What about existing languages? Influenced M# language [2] of Microsoft’s Midori project

49. Isn’t it a Solved Problem? • Adoption surprisingly challenging •

    Ownership not available in mainstream languages • Contender: Rust • Own system [1] influential, but: • Interaction with type inference unclear 12 [2] Gordon et al. Uniqueness and reference immutability for safe parallelism. OOPSLA ’12 [1] Haller and Odersky. Capabilities for uniqueness and borrowing. ECOOP ’10 What about existing languages? Influenced M# language [2] of Microsoft’s Midori project

50. Isn’t it a Solved Problem? • Adoption surprisingly challenging •

    Ownership not available in mainstream languages • Contender: Rust • Own system [1] influential, but: • Interaction with type inference unclear • Midori project not continued 12 [2] Gordon et al. Uniqueness and reference immutability for safe parallelism. OOPSLA ’12 [1] Haller and Odersky. Capabilities for uniqueness and borrowing. ECOOP ’10 What about existing languages? Influenced M# language [2] of Microsoft’s Midori project

51. Affine References in Scala 13

52. Affine References in Scala • LaCasa provides affine references by

    combining two concepts: 13

53. Affine References in Scala • LaCasa provides affine references by

    combining two concepts: • Access permissions 13

54. Affine References in Scala • LaCasa provides affine references by

    combining two concepts: • Access permissions • Encapsulated boxes 13

55. Access Permissions 14

56. Access Permissions • Access to transferable objects controlled by implicit

    permissions 14

57. Access Permissions • Access to transferable objects controlled by implicit

    permissions CanAccess { type C } 14

58. Access Permissions • Access to transferable objects controlled by implicit

    permissions • Type member C uniquely identifies box CanAccess { type C } 14

59. Access Permissions • Access to transferable objects controlled by implicit

    permissions • Type member C uniquely identifies box CanAccess { type C } Box[T] { type C } 14

60. Matching Boxes and Permissions • Type members match permissions and

    boxes • Via path-dependent types • Example: def method(box: Box[T]) (implicit p: CanAccess { type C = box.C }): Unit 15

61. Matching Boxes and Permissions • Type members match permissions and

    boxes • Via path-dependent types • Example: def method(box: Box[T]) (implicit p: CanAccess { type C = box.C }): Unit 15

62. Creating Boxes and Permissions 16

63. Creating Boxes and Permissions class Message { var arr: Array[Int]

    = _ } 16

64. Creating Boxes and Permissions mkBox[Message] { packed => } class

    Message { var arr: Array[Int] = _ } 16

65. Creating Boxes and Permissions mkBox[Message] { packed => } class

    Message { var arr: Array[Int] = _ } 16 LaCasa library

66. Creating Boxes and Permissions mkBox[Message] { packed => } class

    Message { var arr: Array[Int] = _ } 16

67. Creating Boxes and Permissions mkBox[Message] { packed => } class

    Message { var arr: Array[Int] = _ } implicit val access = packed.access val theBox = packed.box … 16

68. Creating Boxes and Permissions mkBox[Message] { packed => } class

    Message { var arr: Array[Int] = _ } sealed trait Packed[+T] { val box: Box[T] val access: CanAccess { type C = box.C } } implicit val access = packed.access val theBox = packed.box … 16

69. Accessing Boxes • Boxes are encapsulated • Boxes must be

    opened for access 17

70. Accessing Boxes • Boxes are encapsulated • Boxes must be

    opened for access mkBox[Message] { packed => implicit val access = packed.access val theBox = packed.box theBox open { msg => msg.arr = Array(1, 2, 3, 4) } } 17

71. Accessing Boxes • Boxes are encapsulated • Boxes must be

    opened for access mkBox[Message] { packed => implicit val access = packed.access val theBox = packed.box theBox open { msg => msg.arr = Array(1, 2, 3, 4) } } Requires implicit access permission 17

72. Consuming Permissions Example: transfering a box from one actor to

    another consumes its access permission 18

73. Consuming Permissions Example: transfering a box from one actor to

    another consumes its access permission mkBox[Message] { packed => implicit val access = packed.access val theBox = packed.box … someActor.send(theBox) // illegal to access `theBox` here! } 18

74. Consuming Permissions Example: transfering a box from one actor to

    another consumes its access permission mkBox[Message] { packed => implicit val access = packed.access val theBox = packed.box … someActor.send(theBox) // illegal to access `theBox` here! } 18 How to enforce this?

75. Permissions and Continuations 19

76. Permissions and Continuations • Make implicit permission unavailable in continuation

    of permission-consuming call 19

77. Permissions and Continuations • Make implicit permission unavailable in continuation

    of permission-consuming call • Scala’s type system is flow-insensitive => use continuation passing 19

78. Permissions and Continuations • Make implicit permission unavailable in continuation

    of permission-consuming call • Scala’s type system is flow-insensitive => use continuation passing • Restrict continuation to exclude consumed permission 19

79. Continuation-Passing Style mkBox[Message] { packed => implicit val access =

    packed.access val theBox = packed.box … someActor.send(theBox) { // make `access` unavailable … } } 20

80. Restricting Continuations • Continuation disallows capturing variables of the type

    of access • Leverage spores 21

81. Restricting Continuations • Continuation disallows capturing variables of the type

    of access • Leverage spores def send(msg: Box[T]) (cont: NullarySpore[Unit] { type Excluded = msg.C }) (implicit p: CanAccess { type C = msg.C }): Nothing 21

82. Restricting Continuations • Continuation disallows capturing variables of the type

    of access • Leverage spores def send(msg: Box[T]) (cont: NullarySpore[Unit] { type Excluded = msg.C }) (implicit p: CanAccess { type C = msg.C }): Nothing 21

83. Intermezzo: Spores Spore [3] = closure • with explicit environment

    • with function type refined by captured types val msg = "hello" val num = 5 spore { val s = msg val x = num (p: Int) => s”Captured vars and param: $s, $x, $p” } 22 [3] Miller, Haller and Odersky. Spores: a type-based foundation for closures in the age of concurrency and distribution. ECOOP ’14

84. Intermezzo: Spores Spore [3] = closure • with explicit environment

    • with function type refined by captured types val msg = "hello" val num = 5 spore { val s = msg val x = num (p: Int) => s”Captured vars and param: $s, $x, $p” } Spore[Int, String] { type Captured = (String, Int) } 22 [3] Miller, Haller and Odersky. Spores: a type-based foundation for closures in the age of concurrency and distribution. ECOOP ’14

85. Spore Trait trait Spore[-T, +R] extends Function1[T, R] { type

    Captured type Excluded } 23

86. Implicit Conversions • Goal:
 Implicitly convert function literals to spores

    • Enables more lightweight syntax • Enables checking excluded types • Example: 24 type SafeSpore[A, B] = Spore[A, B] { type Excluded = SomeExcludedType } val s: SafeSpore[A, B] = (x: A) => { … }

87. Recall Example mkBox[Message] { packed => implicit val access =

    packed.access val theBox = packed.box … someActor.send(theBox) { // `access` unavailable … } } 25

88. Encapsulation Problem: not all types safe to transfer! 26

89. Encapsulation Problem: not all types safe to transfer! 26 class

    Message { var arr: Array[Int] = _ def leak(): Unit = { SomeObject.fld = arr } } object SomeObject { var fld: Array[Int] = _ }

90. Encapsulation • Ensuring absence of data races (“concurrency safety”) requires

    restricting types put into boxes • Requirements for “safe” classes:* • Methods only access parameters and this • Methods only instantiate “safe” classes • Types of fields are “safe” 27 * simplified

91. Encapsulation • Ensuring absence of data races (“concurrency safety”) requires

    restricting types put into boxes • Requirements for “safe” classes:* • Methods only access parameters and this • Methods only instantiate “safe” classes • Types of fields are “safe” 27 “Safe” = conforms to object capability model [3] * simplified

92. Encapsulation • Ensuring absence of data races (“concurrency safety”) requires

    restricting types put into boxes • Requirements for “safe” classes:* • Methods only access parameters and this • Methods only instantiate “safe” classes • Types of fields are “safe” 27 “Safe” = conforms to object capability model [3] * simplified [3] Mark S. Miller. Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control. PhD dissertation, 2006

93. Object Capabilities in Scala • How common are object-capability safe

    classes in Scala? • Results from empirical study: 28

94. LaCasa: Summary • Encapsulated boxes • Alias protection via object

    capability model • Reusing a class requires only a single bit of information • Access permissions via implicits + path-dependent types • Can statically prevent data races • Sound integration with Scala’s local type inference • Not shown: unique fields 29

95. More Contributions 30

96. More Contributions • Formalization: object-oriented core languages 30

97. More Contributions • Formalization: object-oriented core languages • CLC1: type-based

    notion of object capabilities 30

98. More Contributions • Formalization: object-oriented core languages • CLC1: type-based

    notion of object capabilities • CLC2: uniqueness via flow-insensitive permissions 30

99. More Contributions • Formalization: object-oriented core languages • CLC1: type-based

    notion of object capabilities • CLC2: uniqueness via flow-insensitive permissions • CLC3: concurrent extension 30

100. More Contributions • Formalization: object-oriented core languages • CLC1: type-based

     notion of object capabilities • CLC2: uniqueness via flow-insensitive permissions • CLC3: concurrent extension • Soundness proof, establishing heap separation and uniqueness invariants 30

101. More Contributions • Formalization: object-oriented core languages • CLC1: type-based

     notion of object capabilities • CLC2: uniqueness via flow-insensitive permissions • CLC3: concurrent extension • Soundness proof, establishing heap separation and uniqueness invariants • Isolation theorem for processes with shared heap 30

102. Details • Paper to appear at OOPSLA ’16 • Technical

     report: [arXiv:1607.05609] • Mechanization of formal model in Coq 31

103. Status and Plans 32

104. Status and Plans • Prototype implementation:1 • Compiler plug-in for

     Scala 2.11 • Integration with actors (straw man) 32 1 https://github.com/phaller/lacasa

105. Status and Plans • Prototype implementation:1 • Compiler plug-in for

     Scala 2.11 • Integration with actors (straw man) • Ongoing and future work: • Adapters for Akka and other libraries • Empirical study on the effort to adapt existing code • Port to Dotty Scala Compiler 32 1 https://github.com/phaller/lacasa

106. Status and Plans • Prototype implementation:1 • Compiler plug-in for

     Scala 2.11 • Integration with actors (straw man) • Ongoing and future work: • Adapters for Akka and other libraries • Empirical study on the effort to adapt existing code • Port to Dotty Scala Compiler 32 Thank you! 1 https://github.com/phaller/lacasa