Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Retrofitting Concurrency -- Lessons from the engine room

KC Sivaramakrishnan
September 14, 2022

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.

KC Sivaramakrishnan

September 14, 2022
Tweet

More Decks by KC Sivaramakrishnan

Other Decks in Science

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