Kotlin/Native’s strict memory model has been a common topic of interest and/or concern in the community for some time. The arrival of the new memory model will remove what many consider an adoption blocker. However, creating and testing a new memory model is a significant undertaking.
It is tempting to wait until the new memory model is “ready”, but the community can help accelerate the maturing of the platform by testing the new model and reporting bugs.
We are starting to run our open source library tests against the new memory model. Just turning it on for Kermit found a relatively minor issue. If you publish a library, it would be great if you could turn on the new memory model and see if things work. Although everybody’s config is different, here’s how we do it.
Kermit’s Kotlin version is in the gradle.properties file.
GROUP=co.touchlab VERSION_NAME=1.0.0-rc4 KOTLIN_VERSION=1.5.31 # etc...
That makes turning on the memory model simple. We can pass in a different Kotlin version and memory model flag, both as gradle properties.
Currently we run tests 3 times. First with Kotlin 1.5.31, which is our published version. Then Kotlin 1.6.0-M1, but with the strict memory model, then Kotlin 1.6.0-M1 and the new memory model. In the Github Actions script, here are the lines:
- name: Build run: ./gradlew build --no-daemon --stacktrace - name: Build 1.6 run: ./gradlew build -PKOTLIN_VERSION=1.6.0-M1 --no-daemon --stacktrace - name: Build 1.6 nmm run: ./gradlew build -PKOTLIN_VERSION=1.6.0-M1 \ -Pkotlin.native.binary.memoryModel=experimental --no-daemon \ --stacktrace
-PKOTLIN_VERSION=1.6.0-M1 sets the Kotlin verison, and
-Pkotlin.native.binary.memoryModel=experimental turns on the new memory model.
macos-latest is a little old and has Xcode 12.4.
macos-11 has Xcode 12.5, which is required for Kotlin 1.6.0-M1.
Obviously, if you run those once and they work fine, you don’t need to leave them on. We found a minor issue with Kermit, linked above, and I assume it’ll get fixed, or we can just tweak our implementation. I don’t think we’re going to merge the build script changes above. However, once 1.6.0 is live, I think we’ll probably run both memory models for a while.
If you find an issue, I’ve created a simple sample project template.
The project is fairly minimal. Put your failing example in a test. To run code in another thread, call “ThreadHelper.doInBackgroundUnfrozen”. Obviously as the new model matures, the focus will shift more to performance issues than hard “bugs”, but at this point I would expect to see actual bugs here and there.
Ping me in the Kotlin Slack or on Twitter if you’re having issues setting up tests!
When submitting bugs, make sure to select Kotlin as the project. I did it wrong at first. Just FYI.
We are all-in on the tech, and hiring. If you want to jump into KMP with both feet, think about coming to work with us.
We’re also interested in talking to Dev Rel people. We’re not quite hiring for that yet, but looking into it. Would love to get some feedback on what we’re thinking. Please DM me if you’d like to chat.