OK, so I was reading the Kotlin/Native 1.3.50 changelog, and I suddently went “Wow! Wow wow wow! Woooooow!”.
What the hell is the relaxed memory mode???
This can mean so much, and so little. I couldn’t find any mention of it in a non C++ file.
So, what does it bring?
It seems the K/N team are writing a memory mode that do not require freeze/detach semantic to work (probably to be coroutine-friendly)
This is an extremely experimental mode of operations, making all objects usable from concurrent contexts, making reference count updates immediate (instead of delayed in strict mode) and avoiding freezing of top level values. It leaks cyclical gargabe and must never be used for any production mode at the moment.
So… Woooow indeed.
This is kinda game changing.
I hope you realize that, if this ever goes stable, this will be the near death of strict mode. Considering the headaches it brings (mostly due to unforseen exceptions caused by the lack language support). I think most programmers will never go back to strict mode.
Reviewing the mentioned PR, I saw some test about workers accessing mutable main thread data without exception in relaxed mode, but I did not see any test about mutating such data. Will this be supported in relaxed mode ?
This is exactly why kotlin developers are hesitant to introduce this mode. Kotlin is posed as a safe language. And safety is not possible when everyone is using unsafe features. So it is OK, if some lower level libraries like coroutines will be using those features (people know what they are doing there), but if everyone will start using it - it is a catastrophe.
Is there a way to enable it only locally, in a fashion similar to autoreleasepool { } or memScoped? That would allow libraries to take advantage of it after making sure there’s not adding concurrency issues, while keeping the rest of the code safe from there threading issues.
If it is possible, could such a thing work for coroutines, especially when it comes to wrapping blocking code (e.g. using Grand Central Dispatch)? Would it require extra code for each usage or could kotlinx.coroutines enable it under the hood, with no additional config required?
Finally, isn’t relaxed mode similar to what Swift currently has?
I think the idea behind the new memory model is extremely nice, but calling the current (Kotlin/Jvm) “default” model we are used in Kotlin “unsafe” and the implementation of Kotlin/Native “safe” just seems wrong to me. The current implementation has absolutely zero type safety provided by the language itself. Also, everyone using the default memory model would not be a “catastrophe” but the same thing Kotlin devs are used to. Sure, multithreading in the default model might be tricky at some points, but I think concepts provided by coroutines alone are able to provide the same amount of safety than the new memory model.
Native relaxed mode whatever it is has nothing to do with JVM default memory mode. In JVM you have monitors on all objects and access order and synchronization is done by VM itself. It is really convenient, but has some costs and runtime support (and you need to remember that K-N does not have GC). The idea of native memory model is to avoid monitors and provide compile-time safe memory access. I think that in most cases default K-N model is what you want to stick with. Other cases could be resolved with coroutines. Direct access to relaxed mode could be used only for low-level libraries.
Native relaxed mode whatever it is has nothing to do with JVM default memory mode. In JVM you have monitors on all objects and access order and synchronization is done by VM itself. It is really convenient, but has some costs and runtime support (and you need to remember that K-N does not have GC)
Yes, but the discussion is not about the current state of K/N, but what it should be! We just want our code to behave the same, whether we compile against JVM /Android or iOS. We do not want to have some platform just crashing at runtime without any hint by the compiler or even the IDE!
The idea of native memory model is to avoid monitors and provide compile-time safe memory access.
It is not compile-time safe if it just crashes at runtime. This is the absolute opposite of “compile-time safe”. If we would have compile-time safety, then absolutely no one would complain.
I would like to also share this article from Salomon Brys regarding this topic:
Designing a Kotlin memory safe mode
An approach, as proposed here, would give us real compile-time safety and we could even benefit from it when targeting the JVM.