Coroutines and Loom behind the scenes
summary
A live demo runs 100,000 threads sleeping: physical threads take tens of seconds and lots of OS resources, virtual threads start immediately. Project Loom uses new virtual thread per task executor and copies stacks to the heap on yield, cutting per-thread memory to roughly ~2.6KB allocations and ~14KB heap in one preview measurement; Kotlin Coroutines show ~600B allocs and ~360B heap when suspended. Loom pins threads inside native or synchronized code, tooling is preview-level, and coroutines keep structured concurrency and fine-grained async control.
AI-written summary · about
chapters (23)
- 0:00Coroutines and Project Loom intro
- 1:06Loom goals and features
- 3:13Demo: physical vs virtual threads
- 5:20Virtual threads for servers
- 6:47Legacy code thread issues
- 9:58Adopt virtual threads easily
- 11:01Debugging virtual threads
- 12:52Virtual threads save resources
- 15:21Loom limitations
- 17:10Kotlin coroutines intro
- 18:37Loom vs coroutines goals
- 20:43Loom vs coroutines style
- 22:06Event handling and concurrency
- 24:13Kotlin structured concurrency
- 26:02Why structured concurrency matters
- 28:07Loom vs coroutines implementation
- 31:18Memory usage: threads vs coroutines
- 34:48CPU performance challenges
- 35:51IO performance and libraries
- 37:37Tooling for threads and coroutines
- 39:47Best of Loom and coroutines
- 42:12Trade-offs with both
- 44:23Summary
related talks
45mCoroutines and Loom behind the scenes
50mAsync Showdown: Java Virtual Threads vs. Kotlin Coroutines
44mAsync Showdown: Java Virtual Threads vs. Kotlin Coroutines
33mVisualising concurrency with Kotlin
43mCoroutines for Java Developers
46mIntroduction to Coroutines
40mConcurrency made easy with Kotlin Coroutines
38mKotlin coroutines