Retrofitting Concurrency -- Lessons from the engine room

ICFP 2022 Keynote

A new major release of the OCaml programming language is on the horizon. OCaml 5.0 brings native support for concurrency and parallelism to OCaml. While recent languages like Go and Rust have been designed with concurrency in mind, OCaml is not so fortunate. There are millions of lines of OCaml code in production, and none of which was written with concurrency in mind. Extending OCaml with concurrency brings the challenge of not just maintaining backwards compatibility but also preserving the performance profile of single-threaded applications.

In this talk, I will describe the approach taken by the Multicore OCaml project that has helped deliver OCaml 5.0, focusing on what worked well and what didn’t. I hope that these lessons are useful to other researchers building programming language abstractions with the aim to retrofit them onto industrial-strength programming languages.

Transcript

1. Retro
   fi
   tting Concurrency
   Lessons from the engine room
   “KC” Sivaramakrishnan
   Images made with Stable Diffusion
   

   View Slide

2. In Sep 2022…
   OCaml 5.0
   

   View Slide

3. In Sep 2022…
   OCaml 5.0
   Concurrency Parallelism
   

   View Slide

4. In Sep 2022…
   OCaml 5.0
   Overlapped
   execution
   A
   B
   A
   C
   B
   Time
   Concurrency Parallelism
   Effect Handlers
   

   View Slide

5. In Sep 2022…
   OCaml 5.0
   Overlapped
   execution
   A
   B
   A
   C
   B
   Time
   Simultaneous
   execution
   A
   B
   C
   Time
   Concurrency Parallelism
   Effect Handlers Domains
   

   View Slide

6. In this talk…
   OCaml 5.0
   OCaml 4.x
   Multicore OCaml
   

   View Slide

7. Backwards
   Compatibility
   Data Races
   Implementation
   Complexity
   Performance
   Stability
   In this talk…
   OCaml 5.0
   OCaml 4.x
   

   View Slide

8. Journey Takeaways
   

   View Slide

9. In the year 2014…
   18 year-old, industrial-strength, pragmatic,
   functional programming language
   

   View Slide

10. In the year 2014…
    18 year-old, industrial-strength, pragmatic,
    functional programming language
    Industry Projects
    

    View Slide

11. In the year 2014…
    18 year-old, industrial-strength, pragmatic,
    functional programming language
    Industry Projects
    No multicore support!
    

    View Slide

12. Runtime lock
    OCaml C C
    C
    

    View Slide

13. Runtime lock
    OCaml C C
    C
    GIL
    

    View Slide

14. Eliminate the runtime lock
    OCaml OCaml OCaml
    Simultaneous
    execution
    A
    B
    C
    Time
    Parallelism
    Domains
    

    View Slide

15. Eliminate the runtime lock
    OCaml OCaml OCaml
    Simultaneous
    execution
    A
    B
    C
    Time
    Parallelism
    Domains
    GIL
    Sam Gross, Meta, “Multithreaded Python without the GIL”
    

    View Slide

16. Retro
    fi
    tting Challenges ~> Approach
    • Millions of lines of legacy software
    ✦ Most code likely to remain sequential even
    with multicore
    • Cost of refactoring is prohibitive
    

    View Slide

17. Retro
    fi
    tting Challenges ~> Approach
    • Millions of lines of legacy software
    ✦ Most code likely to remain sequential even
    with multicore
    • Cost of refactoring is prohibitive
    Do not break existing code!
    

    View Slide

18. Retro
    fi
    tting Challenges ~> Approach
    • Low latency and predictable performance
    ✦ Great for ~10ms tolerance
    

    View Slide

19. Retro
    fi
    tting Challenges ~> Approach
    • Low latency and predictable performance
    ✦ Great for ~10ms tolerance
    Optimise for GC latency
    before scalability
    

    View Slide

20. Retro
    fi
    tting Challenges ~> Approach
    • OCaml core team is composed of
    volunteers
    ✦ Aim to reduce complexity and
    maintenance burden
    

    View Slide

21. Retro
    fi
    tting Challenges ~> Approach
    • OCaml core team is composed of
    volunteers
    ✦ Aim to reduce complexity and
    maintenance burden
    No separate sequential
    and parallel runtimes
    Unlike -threaded runtime
    

    View Slide

22. Retro
    fi
    tting Challenges ~> Approach
    • OCaml core team is composed of
    volunteers
    ✦ Aim to reduce complexity and
    maintenance burden
    No separate sequential
    and parallel runtimes
    㱺
    Existing sequential programs run just as
    fast using just as much memory
    Unlike -threaded runtime
    

    View Slide

23. Parallel Allocator & GC
    Major Heap
    Minor
    
    
    Heap
    Minor
    
    
    Heap
    Minor
    
    
    Heap
    Domain 0 Domain 1 Domain 2
    Medieval garbage truck according to Stable Diffusion
    

    View Slide

24. Parallel Allocator & GC
    Major Heap
    Minor
    
    
    Heap
    Minor
    
    
    Heap
    Minor
    
    
    Heap
    Domain 0 Domain 1 Domain 2
    Medieval garbage truck according to Stable Diffusion
    

    View Slide

25. Parallel Allocator & GC
    Major Heap
    Minor
    
    
    Heap
    Minor
    
    
    Heap
    Minor
    
    
    Heap
    Domain 0 Domain 1 Domain 2
    Medieval garbage truck according to Stable Diffusion
    

    View Slide

26. Access remote objects
    Domain 0 Domain 1
    X
    Y
    let r = !x
    Major heap
    Minor heaps
    

    View Slide

27. Access remote objects
    Domain 0 Domain 1
    X
    Y
    let r = !x
    promote(y)
    Major heap
    Minor heaps
    

    View Slide

28. Access remote objects
    Domain 0 Domain 1
    X Y
    promote(y)
    y
    Major heap
    Minor heaps
    let r = !x
    

    View Slide

29. Parallel Allocator & GC
    Major Heap
    Minor
    
    
    Heap
    Minor
    
    
    Heap
    Minor
    
    
    Heap
    Domain 0 Domain 1 Domain 2
    Mostly concurrent
    concurrent
    Medieval garbage truck according to Stable Diffusion
    

    View Slide

30. Parallel Allocator & GC
    Major Heap
    Minor
    
    
    

    View Slide

31. Parallel Allocator & GC
    POPL ‘93 Major Heap
    Minor
    
    
    Heap
    Minor
    
    
    Heap
    

    View Slide

32. Parallel Allocator & GC
    ISMM ‘11
    Major Heap
    Minor
    
    
    Heap
    Minor
    
    
    Heap
    

    View Slide

33. Parallel Allocator & GC
    POPL ‘93
    JFP ‘14
    Intel Single-chip Cloud
    Computer (SCC)
    Major Heap
    Minor
    
    
    Heap
    Minor
    
    
    Heap
    

    View Slide

34. Parallel Allocator & GC
    PPoPP ‘18
    H1
    H2 H3
    H4 H5
    disentanglement
    MaPLe
    

    View Slide

35. Parallel Allocator & GC
    JFP ‘14
    PPoPP ‘18
    ICFP ‘22
    

    View Slide

36. JFP ‘14
    Parallel Allocator & GC
    POPL ‘93
    ISMM ‘11
    JFP ‘14
    PPoPP ‘18
    

    View Slide

37. Parallel Allocator & GC
    • Excellent scalability on 128-cores
    ✦ Also maintains low latency on large core counts
    • Mostly retains sequential latency, throughput and
    memory usage characteristics
    Major Heap
    Minor
    
    
    Heap
    Minor
    
    
    Heap
    Minor
    
    
    Heap
    Domain 0 Domain 1 Domain 2
    

    View Slide

38. Parallel Allocator & GC
    Major Heap
    Minor
    
    
    Heap
    Minor
    
    
    Heap
    Minor
    
    
    Heap
    Domain 0 Domain 1 Domain 2
    But …
    

    View Slide

39. Parallel Allocator & GC
    Major Heap
    Minor
    
    
    Heap
    Minor
    
    
    Heap
    Minor
    
    
    Heap
    Domain 0 Domain 1 Domain 2
    But …
    Read
    barrier!
    

    View Slide

40. Parallel Allocator & GC
    Major Heap
    Minor
    
    
    Heap
    Minor
    
    
    Heap
    Minor
    
    
    Heap
    Domain 0 Domain 1 Domain 2
    But …
    Read
    barrier!
    • Read barrier
    ✦ Only a branch on the OCaml side for reads
    ✦ Read are now GC safe points
    ✦ Breaks the C FFI invariants about when GC may be
    performed
    

    View Slide

41. Parallel Allocator & GC
    Major Heap
    Minor
    
    
    Heap
    Minor
    
    
    Heap
    Minor
    
    
    Heap
    Domain 0 Domain 1 Domain 2
    But …
    Read
    barrier!
    • Read barrier
    ✦ Only a branch on the OCaml side for reads
    ✦ Read are now GC safe points
    ✦ Breaks the C FFI invariants about when GC may be
    performed
    • No push-button
    fi
    x!
    ✦ Lots of packages in the ecosystem broke.
    

    View Slide

42. Back to the drawing board (~2019)
    Major Heap
    Minor
    
    
    Heap
    Minor
    
    
    Heap
    Minor
    
    
    Heap
    Domain 0 Domain 1 Domain 2
    Mostly concurrent
    Stop-the-world
    parallel
    

    View Slide

43. Back to the drawing board (~2019)
    Major Heap
    Minor
    
    
    Heap
    Minor
    
    
    Heap
    Minor
    
    
    Heap
    Domain 0 Domain 1 Domain 2
    Mostly concurrent
    Stop-the-world
    parallel
    Bring 128-domains to a stop is surprisingly fast
    

    View Slide

44. Back to the drawing board (~2019)
    Major Heap
    Minor
    
    
    

    View Slide

45. Data Races
    • Data Race: When two threads perform
    unsynchronised access and at least one is a write.
    ✦ Non-SC behaviour due to compiler optimisations and relaxed
    hardware.
    

    View Slide

46. Data Races
    • Data Race: When two threads perform
    unsynchronised access and at least one is a write.
    ✦ Non-SC behaviour due to compiler optimisations and relaxed
    hardware.
    • Enforcing SC behaviour slows down sequential programs!
    ✦ 85% on ARM64, 41% on PowerPC
    

    View Slide

47. Data Races
    • Data Race: When two threads perform
    unsynchronised access and at least one is a write.
    ✦ Non-SC behaviour due to compiler optimisations and relaxed
    hardware.
    • Enforcing SC behaviour slows down sequential programs!
    ✦ 85% on ARM64, 41% on PowerPC
    OCaml needed a
    relaxed memory model
    

    View Slide

48. Second-mover Advantage
    • Learn from the other language memory models
    

    View Slide

49. Second-mover Advantage
    • Learn from the other language memory models
    • DRF-SC, but catch-
    fi
    re semantics on
    data races
    Well-typed OCaml programs don’t go wrong
    

    View Slide

50. Second-mover Advantage
    • Learn from the other language memory models
    • DRF-SC + no crash under data races
    ✦ But scope of race is not limited in time
    • DRF-SC, but catch-
    fi
    re semantics on
    data races
    Well-typed OCaml programs don’t go wrong
    

    View Slide

51. Second-mover Advantage
    • Learn from the other language memory models
    • DRF-SC + no crash under data races
    ✦ But scope of race is not limited in time
    • DRF-SC, but catch-
    fi
    re semantics on
    data races
    Well-typed OCaml programs don’t go wrong
    • No data races by construction
    ✦ Unsafe code memory model is ~C++11
    

    View Slide

52. Second-mover Advantage
    • Learn from the other language memory models
    • DRF-SC + no crash under data races
    ✦ But scope of race is not limited in time
    Advantage: No Multicore OCaml programs in the wild!
    • DRF-SC, but catch-
    fi
    re semantics on
    data races
    Well-typed OCaml programs don’t go wrong
    • No data races by construction
    ✦ Unsafe code memory model is ~C++11
    

    View Slide

53. OCaml memory model (~2017)
    • Simple (comprehensible!) operational memory model
    ✦ Only atomic and non-atomic locations
    ✦ DRF-SC
    ✦ No “out of thin air” values
    ✦ Squeeze at most perf 㱺 write that module in C, C++ or
    Rust.
    

    View Slide

54. OCaml memory model (~2017)
    • Simple (comprehensible!) operational memory model
    ✦ Only atomic and non-atomic locations
    ✦ DRF-SC
    ✦ No “out of thin air” values
    ✦ Squeeze at most perf 㱺 write that module in C, C++ or
    Rust.
    1.19
    

    View Slide

55. OCaml memory model (~2017)
    • Simple (comprehensible!) operational memory model
    ✦ Only atomic and non-atomic locations
    ✦ DRF-SC
    ✦ No “out of thin air” values
    ✦ Squeeze at most perf 㱺 write that module in C, C++ or
    Rust.
    1.19
    

    View Slide

56. OCaml memory model (~2017)
    • Simple (comprehensible!) operational memory model
    ✦ Only atomic and non-atomic locations
    ✦ DRF-SC
    ✦ No “out of thin air” values
    ✦ Squeeze at most perf 㱺 write that module in C, C++ or
    Rust.
    • Key innovation: Local data race freedom
    ✦ Permits compositional reasoning
    1.19
    

    View Slide

57. OCaml memory model (~2017)
    • Simple (comprehensible!) operational memory model
    ✦ Only atomic and non-atomic locations
    ✦ DRF-SC
    ✦ No “out of thin air” values
    ✦ Squeeze at most perf 㱺 write that module in C, C++ or
    Rust.
    • Key innovation: Local data race freedom
    ✦ Permits compositional reasoning
    • Performance impact
    ✦ Free on x86 and < 1% on ARM
    1.19
    

    View Slide

58. • Simple (comprehensible!) operational memory model
    ✦ Only atomic and non-atomic locations
    ✦ No “out of thin air” values
    • Interested in extracting
    f
    i
    

    View Slide

59. Concurrency (~2015)
    • Parallelism is a resource; concurrency is a programming abstraction
    ✦ Language-level threads
    Overlapped
    execution
    A
    B
    A
    C
    B
    Time
    

    View Slide

60. Concurrency (~2015)
    • Parallelism is a resource; concurrency is a programming abstraction
    ✦ Language-level threads
    Overlapped
    execution
    A
    B
    A
    C
    B
    Time
    Async
    Lwt >>=
    

    View Slide

61. Concurrency (~2015)
    • Parallelism is a resource; concurrency is a programming abstraction
    ✦ Language-level threads
    Overlapped
    execution
    A
    B
    A
    C
    B
    Time
    Async
    Lwt >>=
    Synchronous Asynchronous
    Normal calls
    Special calling
    convention
    

    View Slide

62. Concurrency (~2015)
    • Parallelism is a resource; concurrency is a programming abstraction
    ✦ Language-level threads
    Async
    Lwt >>=
    Synchronous Asynchronous
    Normal calls
    Special calling
    convention
    Eliminate function
    colours with
    native concurrency
    support
    — Bob Nystrom
    Overlapped
    execution
    A
    B
    A
    C
    B
    Time
    

    View Slide

63. Concurrency
    • Parallelism is a resource; concurrency is a programming abstraction
    ✦ Language-level threads
    Overlapped
    execution
    A
    B
    A
    C
    B
    Time
    Language & Runtime
    System
    Library
    

    View Slide

64. Concurrency
    • Parallelism is a resource; concurrency is a programming abstraction
    ✦ Language-level threads
    Overlapped
    execution
    A
    B
    A
    C
    B
    Time
    Language & Runtime
    System
    Library
    

    View Slide

65. Concurrency
    • Parallelism is a resource; concurrency is a programming abstraction
    ✦ Language-level threads
    Overlapped
    execution
    A
    B
    A
    C
    B
    Time
    Language & Runtime
    System
    Library
    Maintenance
    Burden
    C and not
    Haskell
    Lack of
    fl
    exibility
    

    View Slide

66. Concurrency
    • Parallelism is a resource; concurrency is a programming abstraction
    ✦ M:N scheduling
    Overlapped
    execution
    A
    B
    A
    C
    B
    Time
    Runtime System
    Language
    Maintenance
    Burden
    C and not
    Haskell
    Lack of
    fl
    

    View Slide

67. Language &
    
    
    Runtime System
    Library Scheduler
    Blackholing
    
    
    (lazy evaluation)
    Concurrency
    

    View Slide

68. Language &
    
    
    Runtime System
    Library Scheduler
    Blackholing
    
    
    (lazy evaluation)
    Hard to undo
    adding a feature
    into the RTS
    Concurrency
    

    View Slide

69. Concurrency
    • Parallelism is a resource; concurrency is a programming abstraction
    ✦ Language-level threads
    Overlapped
    execution
    A
    B
    A
    C
    B
    Time
    Language & Runtime
    System
    Library First-class continuations!
    

    View Slide

70. How to continue?
    PLDI ‘96
    call/1cc
    
    
    Chez Scheme
    

    View Slide

71. call/1cc
    
    
    

    View Slide

72. call/1cc
    
    
    

    View Slide

73. call/1cc
    
    
    

    View Slide

74. Ease of comprehension
    • Effect handler ~= Resumable exceptions + computation
    may be resumed later
    effect E : string
    
    
    
    
    let comp () =
    
    
    print_string (perform E)
    
    
    
    
    let main () =
    
    
    try comp ()
    
    
    with effect E k ->
    continue k “Handled"
    exception E
    
    
    
    let comp () =
    
    
    print_string (raise E)
    
    
    
    let main () =
    
    
    try comp ()
    
    
    with E ->
    print_string “Raised”
    Exception Effect handler
    delimited
    continuation
    

    View Slide

75. Ease of comprehension
    • Effect handler ~= Resumable exceptions + computation
    may be resumed later
    • Easier than shift/reset, control/prompt
    ✦ No prompts or answer-type polymorphism
    effect E : string
    
    
    
    
    let comp () =
    
    
    print_string (perform E)
    
    
    
    
    let main () =
    
    
    try comp ()
    
    
    with effect E k ->
    continue k “Handled"
    exception E
    
    
    
    let comp () =
    
    
    print_string (raise E)
    
    
    
    let main () =
    
    
    try comp ()
    
    
    with E ->
    print_string “Raised”
    Exception Effect handler
    delimited
    continuation
    

    View Slide

76. Ease of comprehension
    • Effect handler ~= Resumable exceptions + computation
    may be resumed later
    • Easier than shift/reset, control/prompt
    ✦ No prompts or answer-type polymorphism
    Effect handlers : shift/reset :: while : goto
    effect E : string
    
    
    
    
    let comp () =
    
    
    print_string (perform E)
    
    
    
    
    let main () =
    
    
    try comp ()
    
    
    with effect E k ->
    continue k “Handled"
    exception E
    
    
    
    let comp () =
    
    
    print_string (raise E)
    
    
    
    let main () =
    
    
    try comp ()
    
    
    with E ->
    print_string “Raised”
    Exception Effect handler
    delimited
    continuation
    

    View Slide

77. OCaml ‘15
    How to continue?
    One-shot delimited continuations
    exposed through effect handlers
    

    View Slide

78. Ease of comprehension ~> Impact
    

    View Slide

79. Ease of comprehension ~> Impact
    

    View Slide

80. Retro
    fi
    tting Effect Handlers
    • Don’t break existing code 㱺 No effect system
    ✦ No syntax and just functions
    

    View Slide

81. Retro
    fi
    tting Effect Handlers
    • Don’t break existing code 㱺 No effect system
    ✦ No syntax and just functions
    • Focus on preserving
    ✦ Performance of legacy code (< 1% impact)
    ✦ Compatibility of tools — gdb, perf
    

    View Slide

82. Retro
    fi
    tting Effect Handlers
    • Don’t break existing code 㱺 No effect system
    • Focus on preserving
    ✦ Performance of legacy code (< 1% impact)
    ✦ Compatibility of tools — gdb, perf
    PLDI ‘21
    

    View Slide

83. Eio — Direct-style effect-based concurrency
    HTTP server performance using 24 cores
    HTTP server scaling maintaining a constant load of
    1.5 million requests per second
    

    View Slide

84. Concurrency (~2022)
    • Parallelism is a resource; concurrency is a programming abstraction
    ✦ Language-level threads
    Overlapped
    execution
    A
    B
    A
    C
    B
    Time
    

    View Slide

85. Concurrency (~2022)
    • Parallelism is a resource; concurrency is a programming abstraction
    ✦ Language-level threads
    Overlapped
    execution
    A
    B
    A
    C
    B
    Time
    

    View Slide

86. Concurrency (~2022)
    • Parallelism is a resource; concurrency is a programming abstraction
    ✦ Language-level threads
    Overlapped
    execution
    A
    B
    A
    C
    B
    Time
    ~2 days ago 🎉
    

    View Slide

87. Takeaways
    

    View Slide

88. Care for Users
    • Transition to the new version should be a no-op or push-
    button solution
    ✦ Most code likely to remain sequential
    

    View Slide

89. Care for Users
    • Transition to the new version should be a no-op or push-
    button solution
    ✦ Most code likely to remain sequential
    • Build tools to ease the transition
    OPAM Health Check: http://check.ocamllabs.io/
    

    View Slide

90. Benchmarking
    Rigorously, Continuously on Real programs
    • OCaml users don’t just run synthetic benchmarks
    

    View Slide

91. Benchmarking
    Rigorously, Continuously on Real programs
    • OCaml users don’t just run synthetic benchmarks
    • Sandmark — Real-world programs picked from wild
    ✦ Coq
    ✦ Menhir (parser-generator)
    ✦ Alt-ergo (solver)
    ✦ Irmin (database)
    … and their large set of OPAM dependencies
    

    View Slide

92. Benchmarking
    Rigorously, Continuously on Real programs
    Program P: OCaml 4.14 = 19s OCaml 5.0 = 18s
    Are the speedups / slowdowns statistically signi
    fi
    cant?
    

    View Slide

93. Benchmarking
    Rigorously, Continuously on Real programs
    Program P: OCaml 4.14 = 19s OCaml 5.0 = 18s
    Are the speedups / slowdowns statistically signi
    fi
    cant?
    • Modern OS, arch, micro-arch effects become signi
    fi
    cant
    at small scales
    ✦ 20% speedup by inserting fences
    

    View Slide

94. Benchmarking
    Rigorously, Continuously on Real programs
    Program P: OCaml 4.14 = 19s OCaml 5.0 = 18s
    Are the speedups / slowdowns statistically signi
    fi
    cant?
    • Modern OS, arch, micro-arch effects become signi
    fi
    cant
    at small scales
    ✦ 20% speedup by inserting fences
    • Tune the machine to remove noise
    

    View Slide

95. Benchmarking
    Rigorously, Continuously on Real programs
    Program P: OCaml 4.14 = 19s OCaml 5.0 = 18s
    Are the speedups / slowdowns statistically signi
    fi
    cant?
    • Modern OS, arch, micro-arch effects become signi
    fi
    cant
    at small scales
    ✦ 20% speedup by inserting fences
    • Tune the machine to remove noise
    • Useful to measure instructions retired along with real time
    

    View Slide

96. Benchmarking
    Rigorously, Continuously on Real programs
    • Are the speedups / slowdowns statistically signi
    f
    i
    

    View Slide

97. Benchmarking
    Rigorously, Continuously on Real programs
    • Are the speedups / slowdowns statistically signi
    f
    i
    

    View Slide

98. Benchmarking
    Rigorously, Continuously on Real programs
    • Continuous benchmarking as a service
    ✦ sandmark.tarides.com
    

    View Slide

99. Invest in tooling
    Reuse existing tools; if not build them!
    

    View Slide

100. Invest in tooling
     Reuse existing tools; if not build them!
     • rr = gdb + record-and-replay debugging
     

     View Slide

101. Invest in tooling
     Reuse existing tools; if not build them!
     • rr = gdb + record-and-replay debugging
     • OCaml 5 + ThreadSanitizer
     ✦ Detect data races dynamically
     

     View Slide

102. Invest in tooling
     Tracing
     GHC’s ThreadScope
     

     View Slide

103. Invest in tooling
     Tracing
     GHC’s ThreadScope
     

     View Slide

104. Invest in tooling
     Tracing
     Runtime Events: CTF-based tracing
     

     View Slide

105. Invest in tooling
     Tracing
     Runtime Events: CTF-based tracing
     

     View Slide

106. Convincing caml-devel
     • Quite a challenge maintaining a separate fork for 7+
     years!
     ✦ Multiple rebases to keep it up-to-date with
     mainline
     ✦ In hindsight, smaller PRs are better
     

     View Slide

107. Convincing caml-devel
     • Quite a challenge maintaining a separate fork for 7+
     years!
     ✦ Multiple rebases to keep it up-to-date with
     mainline
     ✦ In hindsight, smaller PRs are better
     • Peer-reviewed papers adds credibility to the effort
     

     View Slide

108. Convincing caml-devel
     • Quite a challenge maintaining a separate fork for 7+
     years!
     ✦ Multiple rebases to keep it up-to-date with
     mainline
     ✦ In hindsight, smaller PRs are better
     • Peer-reviewed papers adds credibility to the effort
     • Open-source and actively-maintained always
     ✦ Lots of (academic) users from early days
     

     View Slide

109. Convincing caml-devel
     • Quite a challenge maintaining a separate fork for 7+
     years!
     ✦ Multiple rebases to keep it up-to-date with
     mainline
     ✦ In hindsight, smaller PRs are better
     • Peer-reviewed papers adds credibility to the effort
     • Open-source and actively-maintained always
     ✦ Lots of (academic) users from early days
     • Continuous benchmarking, OPAM health check
     

     View Slide

110. Growing the language
     OCaml 4
     OCaml 5
     time
     

     View Slide

111. Growing the language
     OCaml 4
     OCaml 5
     time
     

     View Slide

112. Growing the language
     OCaml 4
     OCaml 5
     time
     

     View Slide

113. Growing the language
     OCaml 4
     OCaml 5
     A few
     researchers
     Lots of
     Engineers
     time
     

     View Slide

114. Growing the language
     OCaml 4
     OCaml 5
     A few
     researchers
     Lots of
     Engineers
     time
     

     View Slide

115. Growing the language
     OCaml 4
     OCaml 5
     A few
     researchers
     Lots of
     Engineers
     time
     Independent
     Contributors
     

     View Slide

116. Where do we go from here?
     OCaml 5.0
     

     View Slide

117. Where do we go from here?
     OCaml 5.0
     

     View Slide

118. Where do we go from here?
     OCaml 5.0
     Effect
     System
     

     View Slide

119. Where do we go from here?
     OCaml 5.0
     Effect
     System
     Backwards compatibility,
     polymorphism, modularity &
     generatively
     

     View Slide

120. Where do we go from here?
     OCaml 5.0
     Effect
     System
     JavaScript
     target
     

     View Slide

121. Where do we go from here?
     OCaml 5.0
     Effect
     System
     JavaScript
     target
     JFP ‘20
     

     View Slide

122. Where do we go from here?
     OCaml 5.0
     Effect
     System
     JavaScript
     target
     Modal
     Types
     

     View Slide

123. Where do we go from here?
     OCaml 5.0
     Effect
     System
     JavaScript
     target
     Modal
     Types
     + Lexically scoped
     typed effect handlers
     Untyped effects
     

     View Slide

124. Where do we go from here?
     OCaml 5.0
     Effect
     System
     JavaScript
     target
     Modal
     Types
     Unboxed
     Types
     Flambda2
     Parallelism
     Control memory
     layout
     Avoid heap
     allocations
     Aggressive
     compiler
     optimisations
     Rust/C-like performance (on demand), with GC as default,
     and the ergonomics and safety of classic ML
     

     View Slide

125. Where do we go from here?
     OCaml 5.0
     Effect
     System
     JavaScript
     target
     Stack
     allocation
     Unboxed
     Types
     Flambda2
     Parallelism
     Control memory
     layout
     Avoid heap
     allocations
     Agressive
     compiler
     optimisations
     Rust/C-like performance (on demand), with GC as default,
     and the ergonomics and safety of classic ML
     

     View Slide

126. Enjoy OCaml 5!
     

     View Slide

127. Top Secret
     

     View Slide