Why User Mode Threads Are Often the Correct Answer
summary
Project Loom introduces virtual threads so a JVM can support millions of threads and let each thread be chosen to run in user mode or as an OS thread, preserving existing threaded APIs so old binaries run unchanged. It contrasts with async/await which requires duplicated I/O APIs and different scheduling defaults. Key tradeoffs: need resizable stacks and backend/compiler support, FFI and stack pointers complicate user-mode threads, and context-switch cost matters far less than throughput governed by Little’s law when I/O dominates.
AI-written summary · about
chapters (13)
- 0:00Intro
- 2:44Concurrency: The Algorithmic View
- 3:45Concurrency: The Syntactic View
- 5:05Process: Unit of Concurrency
- 9:54Thread vs. Async/Await
- 14:36Resizable Stack
- 17:57Performance
- 18:56Syntactic Concurrency: Generators et al.
- 20:18Context-Switching Impact: Generators
- 22:06Concurrency: Transactions
- 26:02Context-Switching Impact: Transactions
- 28:15Conclusion
- 29:02User-Mode Threads
related talks
31mJava Virtual Threads
52mJava Virtual Threads
51mWhat's Looming in Java The Why and What of Project Loom
44mLoom: Revolution or Implementation Detail?
57mUnveiling the Magical Power of Java Virtual Threads
01h 13mProject loom: Modern scalable concurrency for the Java platform
47mThe Challenges of Introducing Virtual Threads to the Java Platform - Project Loom
01h 01mProject Loom: Revolution in Concurrency or Obscure Implementation Detail?