Project Loom: Revolution in Concurrency or Obscure Implementation Detail?
summary
Project Loom claims the JVM can run millions of lightweight threads by using continuations and a small pool of OS-backed carrier threads (~10) to schedule many user-level 1,000,000 virtual threads; demos create millions of sleepers and a bridge Executor spawns a virtual thread per task. Implementation moves suspended stacks onto the heap (stack moved to heap), so deep call chains inflate GC and memory, CPU-bound work lacks preemption, and Jetty’s benchmarks show modest real-world gains — promising but not a free lunch.
AI-written summary · about
chapters (19)
- 0:00Introduction
- 2:42Loom adoption today
- 4:09Threads and virtual threads
- 16:09Cost of platform threads
- 16:31Loom goals and virtual threads
- 21:27Continuations and virtual threads
- 28:51Real-world impact
- 33:47Hello world demo
- 36:54Structured concurrency
- 39:46Tasks over threads
- 41:12Disadvantages of virtual threads
- 46:27Memory overhead concerns
- 48:54Preemption limits
- 51:44Virtual threads vs reactive
- 54:31Switch to virtual threads?
- 55:56Resources and perspectives
- 57:00Q&A: carrier threads
- 59:05Q&A: thread pools
- 1:00:30Closing
related talks
44mLoom: Revolution or Implementation Detail?
01h 13mProject loom: Modern scalable concurrency for the Java platform
51mWhat's Looming in Java The Why and What of Project Loom
50mProject Loom: Helping Write Concurrent Applications on the Java Platform
31mJava Virtual Threads
54mLooming in the cores
32mProject Loom? Better Futures? What’s next for JVM concurrent programming
42mProject Loom Update