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
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 !
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
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é 👏👏👏
Looking forward to eventually seeing a rewrite of the Azure SDK which currently relies on Reactor for its async APIs (although the code itself appears to be high quality, the stack traces are massive and virtually unreadable).
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.
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 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.
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 :)
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?
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.
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?
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..
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.
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.
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)
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.
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.
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.
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
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.
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!
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
the piano is driving me crazy
There is a whole asylum of us now.
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!
Very informative and insightful as always. Highly grateful to have been instructed by you on TH-cam and other platforms.
Great to hear!
Thanks José for making this video,
Really easy to understand the mechanics of Virtual Threads, how they work under the hood.
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!
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é 👏👏👏
Magnificent explanation of pure engineering art. "Project Loom" is indeed a revolutionary masterpiece. 👏👏👏
Nothing to say except: "Awesome!"
I liked to listen the before and after virtual threads, it makes much clear everything.
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 🙂
Amazing explanation...José Explaining both approaches and doing it so well with code is as always great.
Awesome video. Very well structured and presented!
Glad you liked it!
Very great and detailed explanations of the topic!
Thanks!
Perfect presentation ! Thank you ! Pretty that sonar don't support it yet .. hope it is coming soon.
Thank you, that was a great breakdown, I like to see more presentations from this guy again.
Excited to dig into this
Looking forward to eventually seeing a rewrite of the Azure SDK which currently relies on Reactor for its async APIs (although the code itself appears to be high quality, the stack traces are massive and virtually unreadable).
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.
Amazing talk! Really complete and comprehensive! Thank you for that.
This is why I stick with java. The quality of people working on it is amazing.
Perfect! Thank you, Sir!
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 ^__^
Wow.. Loved your session. Super knowledgeable. Thank you very much
I like when this gentleman takes a sip of his coffe!!!
What a nice way to explain java virtual threads. 👏 Thanks Jose !
Fun fact... I once run I/O in parallel Streams !🥲
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.
He explained it so clearly. Bravo
Merci José, super intéressant !
Merci Yves!
Very great explanation. Emphasized and repeated the important parts. 😀
Thanks!
Really thorough explanation!
Great Explanation ! Thank you
Thank you!
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 😉
Great Explanation !!!
Thank you!
Oh là là, une magnifique explication! merci!
Continue ton super travail José ;)
Merci ! 🙂
Awesome explanations sir....Really nicely explained in plain simple language....
Very clear and nice explanations. Well done !
he holding java coffee is just 💥💥💥
Great explanation master
Gracias!
why dont you introduce async await instead completedfuture mess ? :D
"You're not doing I/O in your parallel streams, right?". Oh God, thankfully not. 😅 Very good video.
Amazing feature! Thanks for the explanation too!!
Good explanation as always, thanks a lot for these videos
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 :)
Very great explanation! 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?
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.
José thanks for this clear explanation!
Thanks José!
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...
Best loom explanation 👌
fisrt time i see you , i use to read "java le soir " blog articles !
Awesome explanation
Glad you think so!
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.
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..
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.
Great solution for i/o ops.
Awesome video, thank you very much 😊
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.
Your coffee makes me wants to make a cup of coffee :)
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)
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.
great explanations! thanks
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
Coffee cup, that's just classy
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!
Virtual threads are great, but all I wanna know is where I can get a coffee cup like that?
ForkJoinTask and ForkJoinPool is tgere to do light weight concurrent Thread execution but why Virtual Threads again?
obrigado José!
Clean code, makes wonder what I have always been writing 😢
can anyone explain what does "that would include the probable context switching that you will have to pay" mean at 28:12 ?
thx for this introduction
Best ever.
The captions on this seem to be for a different video, kinda confusing 😶
Thank you for reporting it! It should be fixed now.
where can i get that java cup, please?
good explanation
Merci Beucoup
12:49 In this mess how can i check that?
Wow!
Great video thank you
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
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.
Great content, but the background music is just so annoying!
frontend with java.. why not?
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.
Measure. Don't guess.
You had been drinking that tea for 33 mins. Wasn't that cold?
Can I have a cup of ur coffee sorry I am too excited about features
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!
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.
subtitles are totally unrelated...🤣🤣
I just fixed them. Sorry for the inconvenience.
Is any guess when Oracle will make normal modern docs site like Kotlin, JS,Python has? JavaDocs is ugly
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.
would have been nice to have a video without the music 😅