Reactive ❤️ Loom: A Forbidden Love Story
summary
Quarkus and Netty experiments show a custom Loom scheduler that runs virtual threads on the same platform threads as Netty event loops, implemented in ~400 lines, reduces context switches by ~58% and raises peak throughput from ~60k to ~72k ops/sec (about a ~20% throughput gain), cuts CPU utilization ~33–36% in IO-bound tests, and enables instance consolidation (example: ~2.5k fewer instances for a 10k‑node fleet, ~$7M/year savings); this is a practical Netty core integration with measured trade-offs.
AI-written summary · about
chapters (20)
- 0:00Introduction
- 1:20Not about framework wars
- 2:03Enterprise apps and stacks
- 3:07Open-source benchmark setup
- 5:39Initial benchmark results
- 7:28CPU performance with Perf
- 10:00Quarkus threading model
- 13:53Quarkus threading pain points
- 15:41Loom virtual threads under the hood
- 17:48Custom Loom scheduler wish list
- 19:14Implementing custom scheduler
- 20:18Redesigned benchmark
- 21:41CPU-bound results with scheduler
- 25:34IO-bound metrics
- 29:53Context switch types
- 33:47Efficiency implications
- 35:56Why not replace Netty
- 37:43Scheduler vs ForkJoinPool trade-offs
- 39:12Scheduler observability
- 40:43Q&A
related talks
38mReactive ❤️ Loom: A Forbidden Love Story
41mServices Reloaded Increased Throughput with Project Loom Virtual Threads
35mUntangled: Sneak peek at Project Loom
57mJDK 19 Virtual Threads: Skip Reactive, Boost Throughput
51mQuarkus 3: The Road to Loom for Cheaper, Faster, and Easier Concurrent Applications
51mQuarkus 3: Elevating Java Microservices with Project Loom and Beyond
29mUntangled: Sneak peek at Project Loom
50mVirtual threads - no pain, no gain