Experimenting with kotlin/native in the context of mobile applications has left me with some distaste: whenever I write code and test it on android, it works, but as soon as I compile and test it on iOS, it fails due to the strict memory sharing mode. The mutable addiction is too hard to forget, and despite my best efforts I always end up writing some memory sharing bug.
Is there some switch or extra library/wrapper which makes the jvm backend behave in a similar way to iOS in terms of memory sharing (aka, crashing) so that these mistakes are caught much earlier?
Your problem is actually a very common one, unfortunately, implementing such memory model for JVM would imply performances loss and probably some incompatibilities (though it would be theoretically possible), K/N devs are implementing a “relaxed” memory model that should fix this problem but no release date yet.
For now the only solution seems to avoid sharing any concurrent behavior and stick to sharing models and basic business code.
I would expect the authors of kotlin/native to have some friendship with whoever writes the stdlib of kotlin/jvm and the rest of the language, so they could ask them to build in a mode where passing a compiler switch modifies all object allocations to go through this runtime strict pseudo memory mode emulating the shared memory access behaviour.
Then, android developers could add this switch to their gradle files for local debug/development version and leave it out for release binaries. Performance is not an issue for debug builds, which have other extra stuff going as well stripped from release builds (ie. extra debug logging or development embedded servers like stetho).
Emulation of the memory model for the full JVM would not be necessary, since this would only be for the crossplatform kotlin portion later running as kotlin/native variant. Thus, making strict memory allocation work for generic java bytecode or external libraries would not be an issue anyway, as they are not accessible in the crossplatform kotlin/native part of the program.
I would see two options here: a compiler plugin or bytecode instrumentation. Both would be used to add relevant fields to classes/objects and to adjust the code to verify the strict memory access (at runtime).
In the long run, a compiler plugin is probably the best solution, but those are not stable yet. In cases it may also be possible to determine things statically in which case it probably belongs in a static analysis tool.
I disagree,
there could be a “memory strict” mode that would enforce shared immutability at compile time, without changing anything about the generated bytecode.
Of course, there is a very interesting medium article about it here, but such memory model needs changes in the language where a runtime memory model doesn’t, if jetbrains implemented a compile time memory safety, as does Rust, I would be delighted but I don’t think they will as their primary target is the JVM, which ecosystem is used to unrestricted concurrency
I’m not so sure about that anymore. I think they are pretty invested into MPP now (most of the feature they anounced for 1.4 contribute some way or another to MPP).
Furthermore, Andrey Breslav did say during the KotlinConf 2018 keynote, that they are looking to “fix concurency in the language”.
(I’m the author).