Touchlab will be defaulting to the “new” memory model for anything that’s in dev and/or not hitting production for a few months. That decision will be reviewed if there’s some wild performance issue or bug, but otherwise, we’re just doing it. On Slack, the team collectively decided to make the switch this afternoon.

Why now? Well, the urgency this morning was largely driven by this.

1.6.x will be the last series of native-mt releases and we are effectively decommissioning native-mt in the favour of the new memory model that is supported out-of-the-box in 1.6.0 coroutines release.

…

We encourage developers to try out and evaluate the new MM: that’s our bet, we are investing our resources, development and testing in it and the quality of regular coroutine releases (including pre-release testing, a priority of the bug-fixes, extensive support of existing features and so on) is much higher than of native-mt builds.

The general vibe is to wait until it’s not “experimental”, but if you’ve been working with KMP and Kotlin/Native for any length of time, you’re probably used to “experimental”. If you wait for something resembling “Beta”, the rest of the community will probably have switched long before you did. Such is the life of an early adopter. Also, assuming the new model works “good enough”, more people using it will speed up maturity through feedback.

That’s for client/app work. There are some decisions we (Touchlab), and other library maintainers, need to make around library decisions.

Large portions of Stately, if not all of it, will probably be archived. However, we’ll also need at least an OK implementation of concurrent collections. Next, while Atomic-FU covers a lot of what we’d want for concurrency primitives (atomics, locks, etc), we’ll need a review to see if we want to completely switch over. Stately may continue on as a “simpler” version of some of what Atomic-FU does, or maybe we just need better Atomic-FU samples? TBD.

Koin has a very special Kotlin/Native implementation that forces you to inject on the main thread. I actually implemented that, trying to do it in a way that cooperated with the strict memory model. That all needs to be unwound for sure, and function pretty much the way the JVM version does.

If there’s anything else in the library space you think needs a review, reach out. Most libraries will at least need to start testing on the new model. The big concerns I have are: 1) code that explicitly freezes, or 2) code that relies on the strict model to enforce its safe concurrency. Number 1 is more of an immediate problem, as there are a number of libraries that likely do this in code. You may run into it, but it’s not “risky” in the sense that you’ll just crash but you’ll know it, and nothing “wrong” will happen. Number 2 will be an edge case for sure, but part of the point of the strict model was that you could make assumptions that are no longer true, and you don’t really know what assumptions the author made (certainly the runtime won’t). This is, I think, far less likely of a problem, but it kind of gets at the core of what the strict memory model tried to “fix”. Don’t lose sleep over it, but keep an eye out!

If you are super interested in this kind of stuff, well, we are hiring of course 🙂

Work at Touchlab!

If you want to help define the future of Kotlin, and like living a bit on the edge technically speaking, please reach out!