On the JetBrains Blog, Roman Elizarov just dropped a pretty big piece of news, if you're in the Kotlin/Native and Multiplatform world.

If you still have questions after reading this post and want our input, submit your KN concurrency questions and we’ll get back to you.

The explicitly thread-confined, "frozen" concurrency model, is changing.

I've been talking about this concurrency and runtime model for the past 2+ years. From a safety perspective, there's a lot to like. Unrestricted shared memory access is problematic, to put it mildly. Enforcing some rules at runtime means extra safety, and forces you to think about how your JVM code is architected. Maybe it could be done differently?

Of course, if I take a step back, I've done a lot of content explaining this model over the past couple of years. That would imply that, perhaps, it is difficult for developers to learn. It is certainly a unique model, and the fact that the JVM and Native live by different rules has been a source of some confusion indeed.

Unpacking The Post

I want to highlight some parts of the post and discuss them a bit.

The most important bit was in the TL;DR:

"Existing code will continue to work and will be supported."

It is important to stress that this post is talking about future changes, and that your Native code will be compatible with these future changes.

"To solve these problems, we've started working on an alternative memory manager for Kotlin/Native that would allow us to lift restrictions on object sharing in Kotlin/Native…"

This means the runtime-enforced thread-confinement model will be going away. There was some confusion about what "object sharing" meant. That's not just global objects. It's the full memory management model.

"We plan to introduce it in a way that is mostly compatible with existing code, so code that is currently working will continue to work."

"mostly compatible" might sound like a concern, but unless you have something really exotic going on, it should work fine. Freezing will still be there, but it'll be optional (like Javascript). The annotations will still have implementations, even if they no longer do anything.
Your code will continue to work, and in many cases, work faster.

"and we will be looking at ways to improve Kotlin's approach to working with immutable data in the whole Kotlin language, not just in Kotlin/Native."

This part is interesting. The fact that the JVM and Native worked differently at runtime was one of the biggest issues. Improving immutable data in the language, and applying that to concurrent best practices, sounds like a good thing, but we'll have to see what emerges.

"Meanwhile, we'll continue to support the existing memory manager, and we'll release multithreaded libraries for Kotlin/Native so you can develop your applications on top of them."

This is important. For our apps, we use the multithreaded coroutines branch. We're careful to use it in such a way as to avoid the potential memory leaks discussed in Roman's post, but it is a core part of the library ecosystem. There will be ongoing support for it.

What now?

Well, personally, I'm going to find other things to talk about at conferences :)

Other than that, not a whole lot changes right now. There's no timeline on the memory manager updates, but you can assume it'll be quite a while. This isn't a few months away. That means, for the foreseeable future, if you write Kotlin/Native code, you'll need to understand the frozen model and how to write code in it. All the stuff we've been talking about still applies.

KMP continues to mature as a platform, and the concurrent code you write for Native now will continue to work whenever these updates arrive.

I think we (Touchlab) may start producing content around how to accomplish certain tasks, rather than deeper explanations around the fundamentals ("frozen", etc). Tech recipes, basically. For example, how to use Flow and Sqldelight, how to handle networking in various scenarios, etc. You can mostly hide the details of the current memory model, and you can write code that will transition well when these changes do come.

So, not a whole lot changes right now, but changes certainly are coming. Ultimately, this will improve adoption, which is good for the ecosystem. I'm sure I'll have more to say down the road…