Coroutines and Loom behind the scenes by Roman Elizarov

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

[ericksumargo]

A very structured explanation. Thank you Roman!

[smekalisty]

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

[codersee]

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

[donwald]

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

[zygimantasbruzgys]

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

[haoweishih]

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.

[Blurke]

Every word Roman speaks is interesting

[sunibitsian]

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

[elctmxm]

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?

[TheLuChing]

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

[haimgrn]

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

[eemikegmail]

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

[zhouyuan]

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]

[baer]

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

[stephenmorse]

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.

[Mig]

Loom also has structured concurrency fyi ✌️

[kaqqao]

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

[samson]

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.

[felipelopes]

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.