The JVM automagically swaps out blocking network calls executing in a virtual thread to a non-blocking implementation, so potentially many other requests can be served in the same time.
So you get the benefit of async frameworks, with none of the negatives: the blocking model is trivial to reason about, read, maintain, and works perfectly with tooling (you won’t get an exception in some WhateveScheduler, but at the exact line where it actually happened. Also, can step through with a debugger).
Thanks. Any good books that cover the current java performance landscape but is grounded in the history of what came before?
I used to be heavily involved in java-based server performance and scalability work back in the 90s and 00s but have been working on other things the last decade. But it would be fun to learn more about where things stand.
> I want to fully utilize every CPU and every core I have, why do I want green/virtual threads again?
If your task is CPU bound, then virtual threads don't gain you anything.
On the other hand, if your task is IO bound, e.g. for a webserver, virtual threads make it trivial to spin up a new thread per request, for massive workloads.
It's not the same. The earliest JVMs weren't really thread safe at all but machines were single core so it didn't matter, you could just cooperatively multi-task.
Later HotSpot became thread safe (and fast - a rare achievement), so started using real OS threads so it could go multi-core.
Virtual threads are M:N threading. There are multiple native threads so you can exploit all the cores, and also user-space runtime managed stacks so you can pack way more threads into a process.
> The earliest JVMs weren't really thread safe at all but machines were single core so it didn't matter, you could just cooperatively multi-task.
In the 90s we didn't have multiple cores but we had multiple CPUs. I started using java in '96 on a 2 CPU SPARC and the lack of real thread support was limiting. When green threads was dropped in favor of real (OS) thread support there was much rejoicing. I worked primarily in server performance back in those days.
> Virtual threads are M:N threading.
Solaris had M:N threads early on but it also was dropped.
For me, it's the difference between code structure and resource usage.
Green threads are for a cleaner code structure. async/await comes quite close, but requires function coloring, creating high coupling. The threads have to have low overhead, so that I don't have to think about whether I should create a new one or not.
Kernel threads are for parallelism and scaling across cores.
Is there a good honest writeup on why is this interesting? Very curious.
The earliest JVMs had this, green threads. Performance was terrible so it was eventually dropped.
I want to fully utilize every CPU and every core I have, why do I want green/virtual threads again?