From OCaml 4 to 5 and from Parmap to Effects: A legacy code transition story
summary
Migrating a ~3M LoC OCaml codebase from process-based Parmap forks to multicore Eio and domains, using memtrace and TSan to find issues, produces concrete wins: a small open-source dynamic GC adjusts space_overhead (tuned between ~15–40) by heap size, an eio.submit path behind an experimental flag replaces fork/parmap, and domain-local storage (with “one domain per fiber” discipline) avoids races. Benchmarks and A/B customer dry runs show dramatic RSS reduction and about 10–15% faster scans; rollout is successful and reversible.
AI-written summary · about
chapters (19)
- 0:00Introduction and speaker setup
- 0:47What is SEGP and its use cases
- 2:18Why upgrade to OCaml 5
- 3:42Challenges in OCaml 4 to 5 migration
- 6:54Debugging memory issues with memtrace
- 8:18Tuning the garbage collector
- 11:12Dynamic GC tuning solution
- 12:17Validation and rollout of OCaml 5
- 14:09Overview of SEGP’s parallelism model
- 16:18Problems with fork-based parallelism
- 19:28Memory spikes in fork-based scans
- 20:32Moving to multicore with EIO
- 21:57First step: adding EIO run loop
- 22:39Switching from fork to EIO submit
- 23:45Handling mutable state in multicore
- 26:16Domain local storage solution
- 28:41Rolling out multicore parallelism
- 29:43Results and performance gains
- 30:12Q&A session
related talks
40mWhen magic meets multicore - OCaml and its elegant era of parallelism
23mParallel Sequences in Multicore OCaml
12mComposing Schedulers using Effect Handlers
14mExecution domains in GHC/Haskell (Lightning Talk)
39mThe best multicore-parallelization refactoring you've never heard of
25mPriodomainslib: Prioritized Fine-grained Parallelism for Multicore OCaml
12mOptimistic Concurrency Control for Real-world Go Programs
41mParallel Programming, Fork Join, and Reducers