https://kotlinlang.org logo
#multiplatform
Title
# multiplatform
a

akapanina

06/09/2020, 3:26 PM
Hi folks! I’m Anastasiia, product manager in Kotlin Multiplatform team and I have a funny question for you today 🙂 Have you had cases when strict memory model in Kotlin/Native actually helped you find potential (or real) bugs in Kotlin/JVM part of your Multiplatform project? If yes - please, leave reaction under that message. I’d like to ask you a couple of questions about your case in direct messages. Thanks! p.s. If you’d like to share your story in thread - it’s fine too 🙂
🤔 5
🚫 1
👀 3
k

Konstantin Petrukhnov

06/09/2020, 4:36 PM
It would be hard to answer, as there was almost no opportunity to use kn without strict memory model. Maybe it is protecting, but we don't know. From pre 0.7 kn times, I remember, that ios app was crashing sometimes, but can't recall if it was due to misuse of api(trying to call jvm functions), or trying to modify fields from multiple threads.
r

russhwolf

06/09/2020, 4:49 PM
I think the question is about whether common code which had to adhere to K/N's memory model helped with issues on JVM that also shared that code. Not comparing K/N with the memory model to K/N without.
👌 1
k

Konstantin Petrukhnov

06/09/2020, 4:53 PM
It seems that I answered question that wasn't asked 😄
🙃 1
j

jw

06/10/2020, 2:17 AM
This has never happened for me, but I mostly do Kotlin/JVM and Kotlin/JS. The only Kotlin/Native I've done has been thread-confined things where I've occasionally forgotten a
@ThreadLocal
on a top-level
val
. That being said, I also do a lot of Rust and greatly prefer its strictness. I wish I could apply parts of it to Java and Kotlin. If I could somehow take Kotlin/Native's strict mode and apply it to the JVM I would. Even with the very poor user experience of it being entirely runtime-enforced. But if it came with a bunch of compiler-smarts to analyze source code at compile-time instead of runtime... now we're talking.
The worst part of the JVM's memory model is that it's probabilistic. It's very much "works on my machine" territory, but so much worse because it's more like "works in production 99% of time". I greatly value how the JVM has normalized the memory model across architectures to be consistent, but it's still fraught with runtime foot-guns that I don't like.
I remain convinced that if you started with Rust or Kotlin/Native first and moved to Kotlin/JVM you'd hate it. The controversial memory model is Kotlin/JVM, not Kotlin/Native.
b

Brendan Weinstein

06/10/2020, 8:48 AM
Have not caught bugs due to the strict memory model but have caught race conditions due to testing shared code on both android and iOS where code worked right 99% of the time on android but nearly always failed on iOS
l

louiscad

06/10/2020, 8:50 AM
@Brendan Weinstein "race conditions" is another wording for "bugs", right? So, you did caught race condition bugs that occured rarely on Android thanks to the fact that it always failed in Kotlin/Native, do I understand properly?
b

Brendan Weinstein

06/10/2020, 9:03 AM
@louiscad correct but catching those bugs was not due to seeing InvalidMutabilityException or similar. Just unexpected outcome on iOS and then realizing my code assumed a non guaranteed order of execution
l

louiscad

06/10/2020, 9:06 AM
You mean the fact that it failed on iOS and not on Android was not due to Kotlin/Native in any way but due to iOS specific behavior? Can you tell which specific APIs were used on iOS that were different on Android where it allowed it to work 99% of the time?
b

Brendan Weinstein

06/10/2020, 9:56 AM
Not due to iOS specific behavior. Due to writing pure kotlin code that has a non obvious race condition. I have an example of the code in a write up "The first implementation of dispatchAction did not properly guarantee that downstream flows were collecting. The pipeline happened by luck to not miss any events when run on the android emulator, but the first dispatched events were missed on iOS. One benefit of multiplatform development is race conditions are more likely to pop up early as you are forced to regularly test in dissimilar environments." Example at http://brendanweinstein.com/a-statemachine-for-multithreaded-coroutines-in-kotlin-multiplatform
👍 2