Hi folks! I’m Anastasiia, product manager in Kotli...

# multiplatform

[akapanina]

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 🙂

[Konstantin Petrukhnov]

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.

[russhwolf]

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.

[Konstantin Petrukhnov]

It seems that I answered question that wasn't asked 😄

[jw]

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.

[jw]

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.

[jw]

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.

[Brendan Weinstein]

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

[louiscad]

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

[Brendan Weinstein]

@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

[louiscad]

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?

[Brendan Weinstein]

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