Prepare kotlinx.coroutines for new Native memory model

[qwwdfsad]

Since 1.5.30-dev-2892, the prototype of the new memory model is available in Kotlin/Native (including mark-and-sweep GC, object sharing and cycles collection) and it can be enabled via -memory-model experimental flag (UPD: also requires kotlin.native.cacheKind=none in gradle.properties).

Current develop already passes all tests under the new model, but yet coroutines in their current state can only be used from a single thread.

Here is the list of things that we'd like to get done, first in a separate branch, and later merge it in the mainline, in order to make coroutines work in a multithreaded environment with a new memory model:

• Reuse concurrent source-set and share our multithreaded primitives (notably, linked list) between JVM and K/N. As opposed to native-mt, no platform specific-parts are required here, it should be enough to copy JVM implementation based on atomics and just share it with Native
• Make dispatchers actually multithreaded: introduce newSingleThreadContext backed by worker and make Dispatchers.Default backed by a worker as well
• Copy most of our JVM tests (ones that test actual concurrency, not JVM-specific tweaks) into concurrent source-set. This work is already done as part of the native-mt work, it can be mirrored here.
• Make all tests pass :)
• Make coroutines prepared to KMM: ensure that Dispatchers.Main uses main thread on Darwin.
• Optional: Make Dispatchers.Default to use global dispatch queue and

No other code from native-mt (freezes, cycle breakers, shareable primitives) should be used in this implementation in order to ensure the complete correctness and real-world applicability of new memory model

[andersio]

A couple of random thoughts since libdispatch is mentioned:

• dispatch_get_global_queue(qos, int) by default gives a non-overcommit queue (~ bound by # of logical processors), which seems an ideal execution environment for Kotlin coroutines. Relevant notes from Swift Concurrency.

• I hope we can have a way in common code to influence QoS classes on dispatches by the global queue backed Dispatchers.Default, presumably via coroutine contexts, or at the very least, have custom dispatchers viable (currently not the case on native-mt).

  QoS class influences what CPU cores the kernel schedules tasks/queues on, which is especially relevant on newer Apple SoCs that have asymmetric CPU cores, where lower QoS classes help get work onto energy-efficient cores (and vice versa).

In any case, fingers crossed for the experimental MM support. ❤️

[qwwdfsad]

For the curious ones: we have the very first dev build published: 1.5.1-new-mm-dev1 with Kotlin 1.5.30-M1-136, repo is https://maven.pkg.jetbrains.space/public/p/kotlinx-coroutines/maven. Everything except the global queue support is done.
Safe harbor: no guarantees regarding correctness or performance whatsoever :)

[qwwdfsad]

We released 1.5.1-new-mm-dev2 with all the planned features and even more, with newFixedThreadPoolContext builder.
Apart from that, the performance (compared to dev1) was significantly improved and all the memory leaks were eliminated.

I'm closing this as "fixed", the very next step is #2914