Coroutines and Loom behind the scenes by Roman Elizarov

Подписаться 75 тыс.

Просмотров 32 тыс.

50% 1

Recording brought to you by American Express. americanexpres...
OpenJDK Project Loom is in preview and will become stable any time soon. It offers seemingly similar benefits to Kotlin Coroutines, raising a lot of questions on Kotlin Coroutines and Project Loom coexistence and future. In this session, we'll examine and compare the goals that were put forth during the design of Kotlin Coroutines and Project Loom, we'll look behind the scenes into how these different goals translated into different implementations with different tradeoffs both in the programming model and in the performance. You'll learn which kind of applications should benefit most from the Kotlin Coroutines and from the Project Loom, respectively, how they'll coexist in the future, and where you can benefit from both of them.
Talk by: Roman Elizarov
#kotlinconf23 #Kotlin #Loom #KotlinConf

Опубликовано:

26 сен 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 59

@codersee 11 месяцев назад

The ideal balance between high-level explanation and details. Thank you!

@smekalisty Год назад

If the speaker is Roman then the conversation is about multithreading! 🤘🤘🤘

@ericksumargo694 Год назад

A very structured explanation. Thank you Roman!

@andrybak Год назад

45 minutes and 21 seconds of blocking IO. :-D

@donwald3436 Год назад

Why do conference videos always play the intro jingle at 500% volume then the talk at normal volume?

@andreyliashuk2516 Год назад

As always great job!

@haoweishih4967 Год назад

Can I simply say that Coroutine use the similar mounting/unmounting tech only in the main thread, but not in any other threads which creating by Dispatchers? That's why at the end of the talk we need to use virtualTheadDispatcher.

@zygimantasbruzgys497 7 месяцев назад

This is an excellent explanation! Looking forward to have a Loom and coroutines integration!

@quangtuan202 Год назад

Good explanation!

@zhou7yuan Год назад

what we'll cover today [1:11] The history [1:55] What are Loom's Virtual Threads [3:02] Threads [3:04] Virtual Threads [4:29] Project Loom: Goals [5:00] ~~Existing~~ Legacy code [5:50] Existing server-side code: example [6:44] Handling many connections? expensive [8:55] Existing server-side code: Loom retrofit [9:41] Handling many connections? cheap [14:16] Project Loom: Recap [14:53] Project Loom: Limitations [15:24] cannot unmount code: - running inside native methods - running inside synchronized sections Let's compare Coroutines and Project Loom [17:13] Kotlin Coroutines: Goals [17:22] Project Loom VS Kotlin Coroutines [18:30] focus on | Existing thread APIs | Existing async APIs Best for | Server-side RPC code | Highly concurrent code | Virtual thread per request | Fine-grained concurrency Programing style differences [20:52] Project Loom Style [20:59] Kotlin Coroutines Style [21:56] event handling Structured Concurrency [23:57] Virtual threads are still threads | Coroutines are concurrency-centric [25:45] Implementation differences [27:51] Implemented inside the VM | Implemented in the Kotlin compiler Performance differences [31:11] Performance: Memory [31:17] Virtual Threads [31:26] Coroutines [32:31] Why virtual threads are heavier? [33:05] Performance: CPU [34:30] Performance: IO [35:41] Tooling differences [37:32] Project Loom + Kotlin Coroutines [39:40] weakness of Kotlin Coroutines that Project Loom can help with? Recap [44:22]

@a314 11 месяцев назад

Gold!

@perfectacle Год назад

thanks for great explanation!

@sunibitsian 4 месяца назад

limitations with synchronized pinning can be overcome with locks such as ReentrantLock

@FrancisMcCabe-b2k 7 месяцев назад

Interesting observation about threads vs coroutines. I would go one step further in that analysis: a thread is used to implement a s"service", a coroutine is used to implement a "task". They both have concurrency requirements; satisfied by respective mid-level abstractions. Under the hood, its all about continuations.

@vasigorc Год назад

Ref "no suspend/non-suspend" distinction. Loom has `Continuation.yield`, no?

@9Blurke9 Год назад

Every word Roman speaks is interesting

@TheLuChing 4 месяца назад

42:55 Why for less memory consumption we should use Virtual Threads? Previously Roman told that VT are memory heavier than coroutines.

@Tuligarnio 3 месяца назад

But in this case it's referring to the case when you have to call an existing blocking code.

@rolymeck Год назад

thank you

@reperionkim8187 Год назад

this is why I love kotlin.

@haimgrn 11 месяцев назад

I thought that coroutines loose the stack trace when they are resumed (like callbacks). Was I wrong?

@flykespice 11 месяцев назад

That isn't possible otherwise you wouldn't be able to restore the coroutine state since it all stored in the stack trace.

@stephenmorse8207 Год назад

Great talk, but one thing I feel like was missing - Loom VirtualThreads are preemptive whereas Kotlin Coroutines require cooperative release, so for intensive CPU tasks that run in parallel, Loom will bring addition benefits.

@AndreyLomakin Год назад

That is common misunderstanding. Virtual threads are also cooperative that is why they are pinned in synchronized blocks and that is why JDK code calls yield to unmount virtual threads.

@AndreyLomakin Год назад

Both of them are used for the cases when CPU execution can be "outsourced" but what is more interesting because normal method calls suffer from augmented functionality of virtual threads and you perform CPU intensive tasks in such methods. Especially small ones. Then coroutines will give you more benefits.

@zhamed9587 Год назад

@@AndreyLomakin Who said that performance for normal methods will be affected for virtual threads?

@AndreyLomakin Год назад

@@zhamed9587 You are right, my bad. I confused it with consumption of resources of handling of unmounting of virtual threads.

@SureshG Год назад

@@AndreyLomakin In general synchronized block don't suffer from pinning, only when a long blocking operation is performed inside synchronized block. ForkJoinPool, which is the default scheduler, will manage it using managed blocker will compensate the threads automatically. Coroutine also has this issue if you use blocking APIs somewhere in the call chain. What i heard is they are working on removing the synchronized block pinning issue.

@baer126 4 месяца назад

I wanted to learn kotlin, do I need to learn Java?

@YouTryDie 4 месяца назад

Nope:) you can start with Kotlin. If you have some Java experience you’ll notice Kotlin is less verbose, doesn’t need ;, has type inference, extremely powerful standard lib.

@georgeshalvashvili6270 Год назад

Nice

@聂超群 Год назад

💯

@Mig440 Год назад

Loom also has structured concurrency fyi ✌️

@noraltavir Год назад

And it is in the talk actually.

@Mig440 Год назад

@@noraltavir it is i can see. I like that java is getting it but then again I have no experience with kotlins way of doing it, but I am not really feel like i am missing out on anything major. Loom has the advantage that it can deeply integrate with the jvm whereas kotlin has too do compiler tricks, since it merely uses the jvm as a runtime platform. I dont really like the compiler magic going on in coroutines but I like the plurality of approaches that the jvm affords

@bangonkali Год назад

@@Mig440 the compiler tricks part has an advantage though. It allows kotlin to operate outside jvm. Kotlin solves another set of problems that java as a language is not currently optimized for and that is being able to run multiplatform natively. I wouldn't want to have a jvm runtime for example in my kotlin multiplatform ios project that uses coroutines extensively being dicussed in this presentation. In the end it is simply is that kotlin as a language and it's compiler and the rest of its dev environment has other goals to accomplish compared to the different goals that Java has to fill as well. No right or wrong way just different priorities which open up different opportunities, pros and cons.

@Mig440 Год назад

@@bangonkali i know that kotlins main focus and goal is android and not server side, where java thrives. But kotlin is also used in spring, quarkus gradle and micronaut which austensibly do not care about androids ecosystem, hence my reservations about kotlin.

@bangonkali Год назад

@@Mig440 to each their own 🫡

@kaqqao Год назад

33:43 Did he just try selling function coloring as a good thing?

@GK-rl5du Год назад

I know right :) Just to not dismiss his point of Coroutines providing more fine-grained concurrency. I wanted to understand the following: 1. Ignoring Google scale web services, what are the practical application of such fine-grained concurrency patterns? 2. If I have a big method and I want multiple suspension points within the method. I can just decompose the method into smaller ones and wrap them to run in a separete virtual thread. What's wrong with this approach? The comparision is too artificial IMHO

@alexismanin5239 Год назад

@@GK-rl5du For me the problem is how to manage errors and cancellations across virtual threads ? How to collect individual task results ? As I see it, with java threads (even virtual ones), you have to do that manually, i.e. write code to manage state across your tasks (one thread fails ? You have to stop others manually, because they don't care, they're still running. Want to combine each thread result ? You must manually join futures yourself). Coroutines and colored functions do that for you. They provide a lot of syntactic sugar to reduce the need for boiler-plate. And that is only mostly because of function coloring. In Scala ZIO and in various reactive stream libs, instead of function coloring, they use monads to represent concurrency state/cooperation. It's heavy to use, but still, far better than java.util.concurrent API. And Virtual threads don't change anything at that. So, personnally, I think that function coloring is still a win in that particular case. As I see it, it is a ligthweight method to explicitely define boundaries between a synchronous/blocking environment and an async/non-blocking one.

@oneextrabit 11 месяцев назад

@@alexismanin5239 I think structured concurreny comming in the future will solve this

@felipelopes3171 Год назад

Well, you see how deep he had to go. He had to spend 45 minutes and go into highly technical stuff to argue that there's a difference. Still though, the use case for coroutines 99% of the time is that most server side code today is just threads doing some dumb processing and waiting for IO. For historical reasons, the Java VM used OS threads for this, which is terrible. All modern languages implemented their own concept of concurrence to deal with this. Kotlin coroutines are a clever way that jetbrains found to maintain compatibility with the JVM and much more readable than reactor code. Kudos to them for doing that, but now that Java is finally doing what everyone did before them, coroutines will probably die, as the use cases he mentions are not very common at all.

@GregHib Год назад

Kotlin devs won't use Loom over coroutines. Loom makes coroutines even better. Multiplatform can't use them, Kotlin libraries and apis which use coroutines won't switch. Looms api is clunky; it doesn't expose low level apis such as Continuation so you can't write your own resuming conditions. Kotlin has hot/cold Channels, Flows, Contexts, Sequences, error propagation etc... loom has no equivalent for any of this. As said in the video, while conceptually the same they have totally different use cases.

@shakilahmed4647 Год назад

@@GregHibI strongly believe those resuming api will be exposed eventually and .. loom will replace all JVM based async frameworks

@音羽の夢 9 месяцев назад

@@GregHib Coroutine fans always argue that Coroutine is multiplatform. That's good, but let's be realistic, Java backend devs don't care about multiplatform but only focus on JVM side. So multiplatform from Coroutine is not a benefit in backend development. Now, just because Project Loom is a project directly from Java means that Loom can deeply modify the JVM system to achieve better optimization. Just because of this fact, Loom has a much greater potential than Kotlin Coroutine that can only scratch the surface of JVM. So maybe in the far future when Loom gets more improvement (getting more APIs, more optimization from modifying the JVM, etc), people will choose Coroutine for any other platforms but not on JVM anymore

@samson279 Год назад

Learning Coroutines can take quite a long time to understand and use correctly, whereas with Project Loom everything is straight-forward and easy. That guy is not convincing at all - all I see is Coroutines have some syntax sugar on top of async abstractions, which in most cases are not that useful anymore. To prove his point he should have showed real examples of when Coroutines beat Project Loom, not just general words.

@joshh.2802 11 месяцев назад

Sounds like you just don't really understand coroutines, which is fine. He mentions in this talk that this isn't a deep dive into coroutines. You should watch those if you are interested. His main point, which is that they solve different problems, is correct.

@matrixnorm6672 8 месяцев назад

bla-bla-bla

@ievgenmajor3301 Год назад

No mention about ruzzian war in timeline.

@inferionemperor5219 Год назад

Jetbrains denounced the war and pulled out of Russia. Have any American companies done the same for Iraq/Afghanistan?

@jesprotech Год назад

I think Kotlin will always be associated with Russia. The name comes from a russian island and the team that developed it is mostly russian. As long as this nonsensical war, like all wars, rages on, people will always find ways to associate Kotlin with the war regardless of the fact that the Intellij team pulled the Kotlin team out of Russia.