Reactive ❤️ Loom: A Forbidden Love Story
summary
Quarkus/Vert.x/Netty experiments show virtual threads improve throughput ~30% over classic setups, but a custom Netty scheduler built on Loom yields up to ~37% higher throughput with unchanged app code. Tests use Netty + Jackson + a mock backend (100 clients, 1 ms think time, 2–16 cores) and report ~200x fewer context switches, full CPU-cycle utilization gains (~70% in a microbenchmark), and a JDK ForkJoin timer bug that alone hides ~28% of potential gain.
AI-written summary · about
chapters (16)
- 0:00Reactive and Loom intro
- 1:22Reactive vs Loom debate
- 3:31Benchmark setup CPU workload
- 8:53Context switches CPU use
- 10:39Event loop in Quarkus Netty
- 13:13Loom virtual threads
- 17:59Custom schedulers wishlist
- 19:26Netty virtual thread scheduler
- 20:54Mock server benchmark
- 23:25Performance gains scheduler
- 25:14ForkJoin scheduler bottleneck
- 28:49IO workload CPU savings
- 31:39Context switch efficiency
- 34:50Engineering trade-offs
- 36:37Optimizing use cases
- 37:00Profiling with JS LLMs
related talks
46mReactive ❤️ Loom: A Forbidden Love Story
41mServices Reloaded Increased Throughput with Project Loom Virtual Threads
57mJDK 19 Virtual Threads: Skip Reactive, Boost Throughput
35mUntangled: Sneak peek at Project Loom
51mQuarkus 3: Elevating Java Microservices with Project Loom and Beyond
01h 56mConcurrency Crossroads: Choosing between Reactive Programming & Virtual Threads
51mQuarkus 3: The Road to Loom for Cheaper, Faster, and Easier Concurrent Applications
38mJava Project Loom: Why Should I Care?