TL;DR:
- Virtual Threads = Coroutines = Fibers = Generators = Continuations
- Managed by JVM not OS. Known as user-mode threads.
- The idea is to multiplex many virtual threads on few platform threads. Ratio could be 1000:1 or even more. Platform (kernel) threads are the real threads provided by the OS.
- How do we do that? by yielding to another vthread when a vthread is blocked such as when waiting for I/O.
- So how do we yield? The stack frame at yield point is moved from stack memory to heap memory. When vthread resumes, the frame is loaded back from heap to stack and method can resume from the point where it yielded.
- When the method resumes, it might very well be running on a different platform thread than when it was suspended
- The performance overhead associated with context-switching of a vthread is the cost to move stack frame to heap and vice-versa. This is very small compared to context switch of a platform thread.
- The most interesting part: You write normal synchronous blocking code but wrap it in a vthread. JVM handles the rest – esp. the yielding part. E.g., you write normal synchronous blocking code using a JDBC driver to access a database. JVM will automatically yield the vthread when it detects that its waiting (blocked) for I/O to complete.
- Virtual threads will help in improving performance of I/O-bound applications. Don’t try to run CPU-bound workload in a vthread – it will degrade performance.
- Lastly, this is what Node.js has been doing for more than past 10 years with its beautiful async-await pattern. Multiplex thousands of requests (tasks) on a single platform thread and yield a task whenever its waiting for an I/O operation to complete. Somewhere in a blog post I read how Java vthread eliminates the distinction between a red and blue colored function, but one could argue Node.js is better because you can actually see the yield point in front of your eyes. With Java vthread, its hidden and you don’t see it.
Where to go from here:
siddharth's space 