https://kotlinlang.org logo
#coroutines
Title
# coroutines
c

CLOVIS

01/29/2020, 9:13 PM
Looking at Project Loom (introducing Fibers that look a lot like coroutines to Java), will it change anything in how coroutines work? Will they be reimplemented on top of fibers? Apparently fibers will be able to suspend on blocking IO calls (which coroutines can't, AFAIK)... Will this be taken advantage of in Kotlin?
c

Czar

01/29/2020, 9:19 PM
So far Kotlin was very slow to take advantage of newer JVM features, there are still no optimisations for current versions of JVM above 8. There was a nice talk at KotlinConf comparing current Kotlin with Future Java, what I found particularly interesting was that the speaker talked to some extent about possible optimizations in Kotlin based on new JVM features.
I guess JB wants to fix biggest frustrations first, there are a lot of important rewrites in compiler and tooling going on currently and scheduled to start landing with Kotlin 1.4 Maybe when that's complete optimizations for new JVMs will get prioritized a bit higher than they're now (not prioritized at all).
f

fred.deschenes

01/29/2020, 9:24 PM
Kotlin being able to compile to multiple JDK bytecode versions is probably also a big part of why those optimizations are more complex to implement/maintain than if you know you're just compiling to 1 specific version
c

Czar

01/29/2020, 10:21 PM
Yep, even if you skip the non-LTS releases, it's a lot of branching already. So, I say let's be patient, these performance improvement don't make or break the process for most, development performance - does. I can't wait for IntelliJ to stop hanging for several seconds to tens of seconds on syntax highlighting, refactoring and error analysis.
5
k

kenkyee

01/30/2020, 12:01 PM
Another thing is GraalVM currently only supports JDK8 byte code. If Kotlin supports higher JDK versions, there's a chance I'll no longer be compatible.
g

gildor

01/30/2020, 12:21 PM
Most probably Loom will not be is relevant for Kotlin Coroutines, Kotlin Coroutines is compile time feature (which is also works on all Kotlin platforms), you don't need any runtime support from loom and no real reason to reimplement it But some integration of course possible in future Loom converter for blocking calls may work in Kotlin without additional changes, otherwise it would make them useless for all existing JVM libraroes, so I don't think that any integration is needed Anyway, it's too early for now to be sure, loom is not even close to finalization
4 Views