Excellent talk. The new virtual threads are as much a home run as the nio libs were when they got added to the JDK. Helidon/Nima - the focus on "simple" and "no magic" is delicious!
Thanks so much. Your simple yet practical explanation of virtual threads makes me understand VTs much better now. Will definitely explore Helidon MP for my next Micro-services based projects.
How will virtual threads work with a router - instead of a server? In a traditional server, the requests and responses come from and go to the same connection. Thus, one thread per connection works well. However, in a router requests may come from one connection and have to be forwarded to another connection. In that case, one thread per connection might not work so well. If we assume that the future of distributed computing will be variations of P2P topologies, not traditional client-server topologies - how well will virtual threads help us get there?
We do virtual thread per request(per stream in case of h2) and we have also our own VT powered clients with connection pooling etc, it will work just fine. VTs do the same trick as reactive code by avoiding context switches, in case of VTs it's just hidden behind the scenes. Only real difference is the simplicity of imperative code vs callback hell of reactive paradigm.
Helidon intentionally does not implement the servlet spec. Many common things that applications do using the servlet API you can also do a different way using the JAX-RS API. So if your application is already a JAX-RS application it is possible you can wean it off of the servlet API.
A virtual thread is allocated a platform thread. As soon as Virtual thread performs a blocking operation, JVM will reclaim the allocated platform thread and allocate it to another virtual thread. Once the earlier thread completes it's blocking opreation, it will again request for a platform thread. At this point, what happens if all of platform threads are busy and there isn't any platform thread available ? It will be nice to understand if and how thread life-cycle state flow (ready-to-run --> running --> waiting - dead) changes with the introduction of Virtual threads.
I would like to understand this slightly opposite way. Platform thread gets assigned a virtual thread. As soon as virtual thread blocks, it puts away the blocking virtual thread and a different virtual thead is assigned. It is same as you said but different interpretations. When all the platform threads are busy, this can happen in some cases 1. Pinning - must be avoided in virtual threads. 2. Doing heavy computation - Virtual thread simply do not help here. Better of with normal thread for computation. When used for correct use case, that is highly concurrent IO heavy code that constantly blocks. Virtual thread can handle millions of such virtual thread switching/swapping per second. This means in a web server it can handle millions of connections per second possibly making the dependent remote services (or database) as bottleneck instead of Java server being bottleneck.
> what happens if all of platform threads are busy and there isn't any platform thread available ? The virtual thread scheduler is a new scheduler added which is a ForkJoinPool running in FIFO mode. So if there isn't a platform thread available, the virtual thread will simply wait for a platform thread to be available. And once it is available, the virtual thread will be mounted on to it.
Nice, approachable intro. Though I wouldn’t write it like that at 27:35 on the left, looks quite cluttered, the inner lambda doesn’t capture anything in that context. Identity is just for flattening the fanout result set. Otherwise pretty clear what it does even the way it’s written. One downside is that you gotta unlearn trying to avoid blocking invocations when you do it the fiber way now.🥹 29:26 more like a difference between declarative, functional style and imperative, procedural programming. But debugging is important, of course.
![SAFEPLANET - ดาวเคราะห์ [ THE PLANET ]](http://i.ytimg.com/vi/4X1XL3I_k3c/mqdefault.jpg)
Excellent talk.
The new virtual threads are as much a home run as the nio libs were when they got added to the JDK.
Helidon/Nima - the focus on "simple" and "no magic" is delicious!
Learned more in 40 minutes than in hours of reading medium articles and blog posts.
fr
Great short talk about virtual thread, sir. Thank you so much
Thanks so much. Your simple yet practical explanation of virtual threads makes me understand VTs much better now. Will definitely explore Helidon MP for my next Micro-services based projects.
Wow!!! Java has just been made fun to program in again! Well presented, well Don!
Thx for this presentation. 👍
How will virtual threads work with a router - instead of a server?
In a traditional server, the requests and responses come from and go to the same connection. Thus, one thread per connection works well.
However, in a router requests may come from one connection and have to be forwarded to another connection. In that case, one thread per connection might not work so well.
If we assume that the future of distributed computing will be variations of P2P topologies, not traditional client-server topologies - how well will virtual threads help us get there?
We do virtual thread per request(per stream in case of h2) and we have also our own VT powered clients with connection pooling etc, it will work just fine. VTs do the same trick as reactive code by avoiding context switches, in case of VTs it's just hidden behind the scenes. Only real difference is the simplicity of imperative code vs callback hell of reactive paradigm.
Excellent talk about Helidon Nima, is there any servlet spec implementation on top of Nima? so we can have alternative to tomcat.
Helidon intentionally does not implement the servlet spec. Many common things that applications do using the servlet API you can also do a different way using the JAX-RS API. So if your application is already a JAX-RS application it is possible you can wean it off of the servlet API.
Great presentation. We are from Bangalore JUG. Shall we get the speakers contact.
Helidon cli is useful
A virtual thread is allocated a platform thread.
As soon as Virtual thread performs a blocking operation, JVM will reclaim the allocated platform thread and allocate it to another virtual thread.
Once the earlier thread completes it's blocking opreation, it will again request for a platform thread.
At this point, what happens if all of platform threads are busy and there isn't any platform thread available ?
It will be nice to understand if and how thread life-cycle state flow (ready-to-run --> running --> waiting - dead) changes with the introduction of Virtual threads.
I would like to understand this slightly opposite way.
Platform thread gets assigned a virtual thread. As soon as virtual thread blocks, it puts away the blocking virtual thread and a different virtual thead is assigned. It is same as you said but different interpretations.
When all the platform threads are busy, this can happen in some cases
1. Pinning - must be avoided in virtual threads.
2. Doing heavy computation - Virtual thread simply do not help here. Better of with normal thread for computation.
When used for correct use case, that is highly concurrent IO heavy code that constantly blocks. Virtual thread can handle millions of such virtual thread switching/swapping per second. This means in a web server it can handle millions of connections per second possibly making the dependent remote services (or database) as bottleneck instead of Java server being bottleneck.
> what happens if all of platform threads are busy and there isn't any platform thread available ?
The virtual thread scheduler is a new scheduler added which is a ForkJoinPool running in FIFO mode. So if there isn't a platform thread available, the virtual thread will simply wait for a platform thread to be available. And once it is available, the virtual thread will be mounted on to it.
Why "modern"??
Ok, I'll assume it's for the people who always criticize Java 7 in 2023 (java 21) to stop and watch this video.
Nice, approachable intro. Though I wouldn’t write it like that at 27:35 on the left, looks quite cluttered, the inner lambda doesn’t capture anything in that context. Identity is just for flattening the fanout result set. Otherwise pretty clear what it does even the way it’s written. One downside is that you gotta unlearn trying to avoid blocking invocations when you do it the fiber way now.🥹
29:26 more like a difference between declarative, functional style and imperative, procedural programming.
But debugging is important, of course.