Coroutines and Loom behind the scenes by Roman Elizarov

Рет қаралды 30,398

Жыл бұрын

Recording brought to you by American Express. americanexpress.io/kotlin-jobs
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

Пікірлер: 59

@codersee 9 ай бұрын

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

@andreyliashuk2516 Жыл бұрын

As always great job!

@perfectacle Жыл бұрын

thanks for great explanation!

@quangtuan202 Жыл бұрын

Good explanation!

@zygimantasbruzgys497 4 ай бұрын

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

@reperionkim8187 Жыл бұрын

this is why I love kotlin.

@rolymeck Жыл бұрын

thank you

@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.

@donwald3436 Жыл бұрын

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

@9Blurke9 Жыл бұрын

Every word Roman speaks is interesting

@sunibitsian Ай бұрын

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

@user-el9ct4mx8m 5 ай бұрын

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.

@georgeshalvashvili6270 Жыл бұрын

Nice

@TheLuChing Ай бұрын

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

@Tuligarnio Ай бұрын

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

@user-mh4sz7yu1p Жыл бұрын

💯

@vasigorc 11 ай бұрын

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

@haimgrn 9 ай бұрын

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

@flykespice 8 ай бұрын

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

@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 9 ай бұрын

Gold!

@eemikegmail 5 ай бұрын

I honestly don’t quite get what he mean fine grain concurrency. And how coroutine solve that issue.

@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 🫡

@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 2 ай бұрын

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

@YouTryDie 2 ай бұрын

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.

@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 9 ай бұрын

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

@samson279 9 ай бұрын

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 8 ай бұрын

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.

@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 9 ай бұрын

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

@user-wt9vk2xo6v 7 ай бұрын

@@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

@matrixnorm6672 5 ай бұрын

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.

@JohnDoe-pm8cz 10 ай бұрын

you washed your brain too much, stop it