If Mr. José Paumard is not an actor, maybe he should. This video is pretty funny!!! 😅 Nice to get a chance to delve into such complex content in a lighter and interesting way. Thank you, José 👏👏👏
Thank you so much for your excellent presentation, Sir! Please give me some short explanations regarding the differences between Virtual Threads and the NIO mechanism. I appreciate your time.
Is it true that virtual threads (called green threads) were already present in java 1.1 but then abandoned in 1.3 as too limiting? Could you please elaborate on what was consider the limitation then and how these limitations are overcome with this new implementation?
Green threads were indeed an attempt at doing the same kind of things. But they were not working in the same way. One of the major difference was that a green thread was actually bound to a single platform thread, and could not jump from one another. There were other caveats, and in the end green threads were removed from the platform. Virtual threads are a totally new feature, with the same ideas in mind, but implemented in a complete new way.
One stupid question may be, What a raw implementation of creating a platform/kernel thread would like? If I want to create a platform/kernel thread without depending on Thread class how can i do it? Just curious to know if it is documented somewhere to read internals.
Thanks José for presenting this in such an easy way to understand, especially on the limitations of the system. I did read in some places that synchronized code would always be pinned to a platform thread which was detering me from investigating moving to jdk 21 to benefit from virtual threads given the fair amount of synchronized code we unfortunately have in our legacy applications. But I will now revisit that plan with the information you provided. Thanks again
Thanks, Jose. I think your explanations are just at the right balance between technical and understandable. Your shorts are almost the only shorts I watch on TH-cam! Please keep on that way. I also need a copy of your mug of coffee, for it seems to empty itself only at the end of your task ;-). Merci !
Clarifying question: 28:43, is this saying IO inside parallelStreams is/was always a bad idea… or is the point that it’s only a bad idea *now that Virtual Threads exist*?
Always been a bad idea. Remember, its using a thread *somehwhere* its just doing the bookkeeping for you. By default, you'll share the same thread pool w/all parallel streams in your app. That means you could starve the pool intended for CPU bound tasks (like `sum()`) while its waiting for IO
@@adambickford8720 that makes sense. Just so I’m clear, for those at or below Java 17, is the recommended alternative to use a separate, dedicated thread pool for scheduling and orchestrating blocking IO?
@@2k5325i Exactly right. Its also perfectly fine to block those I/O threads as that's the intent and it won't 'starve' other threads. It normal to have far more I/O threads than cores. Just remember each thread takes memory and overhead to manage, even if idle. If you're CPU bound, more threads than cores makes things worse, not better, virtual or not. Remember that you'll potentially want to pool connections too and now you have to multiplex threads to connections. It never ends :)
Thank you .. but could you please please please mute the background music as it is distracting and irritating. The music is unnecessary for this type of content. Content itself is great but the music makes it feel like when you are studying for an exam and you hear blast of TV noise coming from the other room.Thanks again
Absolutely fantastique explainer as usual! Also so excited for Java 21 :D But as an aside, please, please, remove the white flashing transitions. It hurts my old eyes and I can think that folks with photo-sensitivity or epilepsy can have a hard time with these as well. Cheers, Niss
Hi @Java / @JosePaumard, I want to understand the following - 1. How is it ensured that all the blocking operations invoked by any arbitrary code (excluding native method calls and synchronized blocks) from a virtual thread are managed by the Continuation framework? Have all the potential blocking points in the JDK been identified and adapted to support this? 2. Consider a third-party library that is confirmed not to use native methods or synchronized blocks. While calling it from a virtual thread, is it still necessary to manually verify that it will not accidentally block the underlying platform thread? Thanks.
If my project is using java8 and upgrade to java21, will my old blocking code run in a virtual thread be pinned back to the platform thread? (old code includes old libraries like JDBC, GRPC, REST CLIENT)
Thanks. Great explanation of main topic plus extra tips. My ears satisfied when I've heard about IO in parallel computation. You said that stack is copied into the heap space. Stack is stored in RAM in stack memory. To me Java can simply keep all stacks in place, and switch between them by overriding a pointer to current stack in OS thread. Does it really need to be copied?
Does In-memory computation mean a task for CPU bound job? If so, computing some tasks with virtual thread isn't good cuz virtual thread has more overhead than planform thead. (of course virtual thread is way much better when it comes to blocking). Do I get right?
wow, an absolutely masterfully extended way of saying: "cheaper threads, to better hide the complexity of asynchroneous". I was just wondering why not Promises, but Virtual Threads (with essentially non-public async framework) instead. Now i know. Thanks
wonderful presentation jose. cant wait to start using this. Why are we not supposed to call an IO operation or say a rest api calls in parallel streams? is there any reasons?
Thank you! I/O operations in intermediate or terminal methods of streams: it's probably not working as you think. Same for parallel streams, you don't have any hand on how your data will be split, and to which point. So it gives a pretty unpredictable way of computing things. Pulling data from an I/O source: that's ok, this is what reader.lines() is doint. Don't do it in parallel though, it's useless.
Read my earlier post please and please help me to answer following question:"Why does Java sais that it invented something called virtual threads, when it was invented many years ago for C? How can something that is allready invented be invented again?"
@@JosePaumard Sorry for my not correctly using the english language. I am not used to it 100%. I try my best. You are right that Java can't speak :-))) What I meant was the project and or company of course. I repeated looking the video again. It is said that JDK introduced Virtual Threads. So this does not mean that they invented it. So you are right virtual threads are not an invention of Java (project/company). Thank for helping to clearify this point. In short:"Virtual threads were not invented by JAVA (project/company.) Best regards.
No, virtual threads were created not to have the async await pattern. It solves this bad pattern in languages, where there are async methods and others not, because when you start to have a method with async it contaminates the others. Like when you use reactive patterns with Flux, RxJava, CompletableFuture..
There is no reason that your code run faster on virtual threads. In the end, it is a platform thread that executes your virtual thread. What you should run in a virtual thread is I/O operations. Then you will get better performances, because blocking is handled in a much better way than asynchronous code.
I've been working with Reactor for three years now, and while Reactor is an excellent framework, the price to pay for creating and maintaining asynchronous software is huge. This change comes not a moment too soon.
tickering reactor is a lot of fun, but not so much when comes to production and teamwork. The virtual thread makes reactor useless to me the moment I found it.
That's the job of structured concurrency. It is still in preview in 21, reason why I chose not to cover it here. You can watch how it is working on this channel: th-cam.com/video/2nOj8MKHvmw/w-d-xo.html
@JosePaumard yeah, it does seem like these frameworks do a lot of complicated stuff to decouple concurrent tasks from threads to try deal with blocking stuff, which is what virtual threads do.
the piano is driving me crazy
There is a whole asylum of us now.
Awesome video. Very well structured and presented!
Glad you liked it!
If Mr. José Paumard is not an actor, maybe he should. This video is pretty funny!!! 😅
Nice to get a chance to delve into such complex content in a lighter and interesting way.
Thank you, José 👏👏👏
Perfect presentation ! Thank you ! Pretty that sonar don't support it yet .. hope it is coming soon.
Great Explanation ! Thank you
Thank you!
Oh là là, une magnifique explication! merci!
Thank you so much for your excellent presentation, Sir!
Please give me some short explanations regarding the differences between Virtual Threads and the NIO mechanism.
I appreciate your time.
Very clear and nice explanations. Well done !
Thanks José!
fisrt time i see you , i use to read "java le soir " blog articles !
How virtual threads are better than non-blocking I/O (Java NIO) created 20 years ago and extensively used today?
nio requires so mich code change it mightnt worth it
why dont you introduce async await instead completedfuture mess ? :D
Wow!
Is it true that virtual threads (called green threads) were already present in java 1.1 but then abandoned in 1.3 as too limiting? Could you please elaborate on what was consider the limitation then and how these limitations are overcome with this new implementation?
Green threads were indeed an attempt at doing the same kind of things. But they were not working in the same way. One of the major difference was that a green thread was actually bound to a single platform thread, and could not jump from one another. There were other caveats, and in the end green threads were removed from the platform.
Virtual threads are a totally new feature, with the same ideas in mind, but implemented in a complete new way.
One stupid question may be, What a raw implementation of creating a platform/kernel thread would like? If I want to create a platform/kernel thread without depending on Thread class how can i do it? Just curious to know if it is documented somewhere to read internals.
12:49 In this mess how can i check that?
content is too good, however the piano background music is driving me crazy. Anyway thanks Jose
How many cups of coffee have you been drinking, sir?
One. Just one, really 😄
@@JosePaumard Your presentations are amazing, sir. Keep up the good work 👍
@@VuLinhAssassinThank you!
Is any guess when Oracle will make normal modern docs site like Kotlin, JS,Python has? JavaDocs is ugly
FInally! We can just let our threads block on IO, as God intended!!!
My first thought watching this was "oh god, no".
Your page becomes my number #1 source of learning Java faster. I love to always watch this channel. Thanks for all you do, Sir.
Thank you!
Thanks José for presenting this in such an easy way to understand, especially on the limitations of the system. I did read in some places that synchronized code would always be pinned to a platform thread which was detering me from investigating moving to jdk 21 to benefit from virtual threads given the fair amount of synchronized code we unfortunately have in our legacy applications. But I will now revisit that plan with the information you provided. Thanks again
Thank you! Glad I could help!
Never heard anybody else explain in such a detailed and simple/friendly way. Congratulations!
Thanks, Jose.
I think your explanations are just at the right balance between technical and understandable. Your shorts are almost the only shorts I watch on TH-cam! Please keep on that way.
I also need a copy of your mug of coffee, for it seems to empty itself only at the end of your task ;-).
Merci !
Thank you Laurent!
This is why I stick with java. The quality of people working on it is amazing.
Very informative and insightful as always. Highly grateful to have been instructed by you on TH-cam and other platforms.
Great to hear!
Clarifying question: 28:43, is this saying IO inside parallelStreams is/was always a bad idea… or is the point that it’s only a bad idea *now that Virtual Threads exist*?
Always been a bad idea. Remember, its using a thread *somehwhere* its just doing the bookkeeping for you. By default, you'll share the same thread pool w/all parallel streams in your app. That means you could starve the pool intended for CPU bound tasks (like `sum()`) while its waiting for IO
@@adambickford8720 that makes sense. Just so I’m clear, for those at or below Java 17, is the recommended alternative to use a separate, dedicated thread pool for scheduling and orchestrating blocking IO?
@@2k5325i Exactly right. Its also perfectly fine to block those I/O threads as that's the intent and it won't 'starve' other threads. It normal to have far more I/O threads than cores. Just remember each thread takes memory and overhead to manage, even if idle.
If you're CPU bound, more threads than cores makes things worse, not better, virtual or not.
Remember that you'll potentially want to pool connections too and now you have to multiplex threads to connections.
It never ends :)
Thank you .. but could you please please please mute the background music as it is distracting and irritating. The music is unnecessary for this type of content. Content itself is great but the music makes it feel like when you are studying for an exam and you hear blast of TV noise coming from the other room.Thanks again
Maybe low the volume little bit or some other types of music.
Thanks José for making this video,
Really easy to understand the mechanics of Virtual Threads, how they work under the hood.
Thank you!
Absolutely fantastique explainer as usual! Also so excited for Java 21 :D
But as an aside, please, please, remove the white flashing transitions. It hurts my old eyes and I can think that folks with photo-sensitivity or epilepsy can have a hard time with these as well.
Cheers,
Niss
Thank you Niss! I wasn't aware of this problem with flashing transitions, thank you for reporting. I will change that in the next videos.
Merci Infinimenent@@JosePaumard
Always a pleasure to follow your vids ^__^
Can I have a cup of ur coffee sorry I am too excited about features
Very great explanation. Emphasized and repeated the important parts. 😀
Thanks!
Continue ton super travail José ;)
Merci ! 🙂
Greatly and well presented. Keep up the good work Jose! We need more on this topic
Thank you! I will publish more when we have the new version of Structured Concurrency. Stay tune!
José, I am becoming addicted to your cup of Java 🙂
Very great and detailed explanations of the topic!
Thanks!
Hi @Java / @JosePaumard, I want to understand the following -
1. How is it ensured that all the blocking operations invoked by any arbitrary code (excluding native method calls and synchronized blocks) from a virtual thread are managed by the Continuation framework? Have all the potential blocking points in the JDK been identified and adapted to support this?
2. Consider a third-party library that is confirmed not to use native methods or synchronized blocks. While calling it from a virtual thread, is it still necessary to manually verify that it will not accidentally block the underlying platform thread?
Thanks.
Nothing to say except: "Awesome!"
If my project is using java8 and upgrade to java21, will my old blocking code run in a virtual thread be pinned back to the platform thread? (old code includes old libraries like JDBC, GRPC, REST CLIENT)
"You're not doing I/O in your parallel streams, right?". Oh God, thankfully not. 😅 Very good video.
Perfect! Thank you, Sir!
Thanks. Great explanation of main topic plus extra tips. My ears satisfied when I've heard about IO in parallel computation.
You said that stack is copied into the heap space. Stack is stored in RAM in stack memory. To me Java can simply keep all stacks in place, and switch between them by overriding a pointer to current stack in OS thread.
Does it really need to be copied?
Excited to dig into this
Merci José, super intéressant !
Merci Yves!
Great Explanation !!!
Thank you!
ForkJoinTask and ForkJoinPool is tgere to do light weight concurrent Thread execution but why Virtual Threads again?
The captions on this seem to be for a different video, kinda confusing 😶
Thank you for reporting it! It should be fixed now.
I liked to listen the before and after virtual threads, it makes much clear everything.
Does In-memory computation mean a task for CPU bound job? If so, computing some tasks with virtual thread isn't good cuz virtual thread has more overhead than planform thead. (of course virtual thread is way much better when it comes to blocking). Do I get right?
Yes. Virtual threads are only interesting if your task blocks.
You had been drinking that tea for 33 mins. Wasn't that cold?
Measure. Don't guess.
wow, an absolutely masterfully extended way of saying: "cheaper threads, to better hide the complexity of asynchroneous". I was just wondering why not Promises, but Virtual Threads (with essentially non-public async framework) instead. Now i know. Thanks
can anyone explain what does "that would include the probable context switching that you will have to pay" mean at 28:12 ?
wonderful presentation jose. cant wait to start using this. Why are we not supposed to call an IO operation or say a rest api calls in parallel streams? is there any reasons?
Thank you!
I/O operations in intermediate or terminal methods of streams: it's probably not working as you think. Same for parallel streams, you don't have any hand on how your data will be split, and to which point. So it gives a pretty unpredictable way of computing things.
Pulling data from an I/O source: that's ok, this is what reader.lines() is doint. Don't do it in parallel though, it's useless.
Great explanation master
Gracias!
Read my earlier post please and please help me to answer following question:"Why does Java sais that it invented something called virtual threads, when it was invented many years ago for C? How can something that is allready invented be invented again?"
Sorry but I don't think Java ever said that it invented Virtual Threads. Where did you saw that?
@@JosePaumard Sorry for my not correctly using the english language. I am not used to it 100%. I try my best. You are right that Java can't speak :-))) What I meant was the project and or company of course. I repeated looking the video again. It is said that JDK introduced Virtual Threads. So this does not mean that they invented it. So you are right virtual threads are not an invention of Java (project/company). Thank for helping to clearify this point. In short:"Virtual threads were not invented by JAVA (project/company.) Best regards.
@@nejathakan5521 We agree: Java can't speak :-))) Best!
Very nice new feature! Thanks. Is there some chance to see in Java mechanism like in C# async/await?
No, virtual threads were created not to have the async await pattern.
It solves this bad pattern in languages, where there are async methods and others not, because when you start to have a method with async it contaminates the others. Like when you use reactive patterns with Flux, RxJava, CompletableFuture..
Amazing talk! Really complete and comprehensive! Thank you for that.
great explanations! thanks
frontend with java.. why not?
where can i get that java cup, please?
Performance vs classical threads is so disappointing. There is nearly no diff
There is no reason that your code run faster on virtual threads. In the end, it is a platform thread that executes your virtual thread. What you should run in a virtual thread is I/O operations. Then you will get better performances, because blocking is handled in a much better way than asynchronous code.
Great solution for i/o ops.
Thanks your great talk!
so... should we worry about the platform threads are enough, how can we observe it, eg: queue size, active thread number...
Amazing explanation...José Explaining both approaches and doing it so well with code is as always great.
Wow.. Loved your session. Super knowledgeable. Thank you very much
😂
Merci Beucoup
but this feature isnot new. it was produce in
java 19
Yes. The new thing is that it is now a final feature. And there were some updates too.
Best loom explanation 👌
subtitles are totally unrelated...🤣🤣
I just fixed them. Sorry for the inconvenience.
Magnificent explanation of pure engineering art. "Project Loom" is indeed a revolutionary masterpiece. 👏👏👏
Awesome explanation
Glad you think so!
Best ever.
obrigado José!
Awesome explanations sir....Really nicely explained in plain simple language....
Thank you, that was a great breakdown, I like to see more presentations from this guy again.
Clean code, makes wonder what I have always been writing 😢
Awesome video, thank you very much 😊
Very great explanation! Thank you sir
Amazing feature! Thanks for the explanation too!!
Good explanation as always, thanks a lot for these videos
José thanks for this clear explanation!
Your coffee makes me wants to make a cup of coffee :)
I like when this gentleman takes a sip of his coffe!!!
he holding java coffee is just 💥💥💥
He explained it so clearly. Bravo
Coffee cup, that's just classy
Great video thank you
thx for this introduction
I've been working with Reactor for three years now, and while Reactor is an excellent framework, the price to pay for creating and maintaining asynchronous software is huge. This change comes not a moment too soon.
tickering reactor is a lot of fun, but not so much when comes to production and teamwork. The virtual thread makes reactor useless to me the moment I found it.
good explanation
how do you launch 2 or more io ops in parallel and wait for both like when parts of your data flow fan out and fan in
That's the job of structured concurrency. It is still in preview in 21, reason why I chose not to cover it here.
You can watch how it is working on this channel: th-cam.com/video/2nOj8MKHvmw/w-d-xo.html
Thank you for this - that coffee must have been getting cold by the end
Not quite, that's a good cup, it can keep the coffee warm for long enough 😉
Hrm.. so would reactive mechanisms need to bother with all that they do? Or just use these for the blocking stuff?
Use them for the blocking stuff. And ask yourself: do you need to write your code in an async way. Maybe you don't.
@JosePaumard yeah, it does seem like these frameworks do a lot of complicated stuff to decouple concurrent tasks from threads to try deal with blocking stuff, which is what virtual threads do.
@@--Nath-- Exactly.
Please remove background music.
What a nice way to explain java virtual threads. 👏 Thanks Jose !
Fun fact... I once run I/O in parallel Streams !🥲
would have been nice to have a video without the music 😅
Why Germans are so good at everything