New Memory Model

[kpgalligan]

The new memory model is coming on quickly, and with that, there are existential discussions around Stately for sure, but also around what kinds of things we'll want for the new memory model. Stately was created to support working with Kotlin/Native's "strict" model. That includes expect/actual helpers, concurrency primitives, and things like collections.

I'd like to get feedback on what things people may want to keep vs what gets removed. By "removed" I mean we'll publish updates if needed, likely through Kotlin 1.7, but eventually, these modules will be removed permanently (or somebody can fork them, etc).

Current features

stately-collections

The collections in this module are implemented with AtomicReference. The performance is frankly terrible, but they work. We haven't been using them a whole lot internally, but once in a while there's a good use case. stately-collections is definitely going away with the new memory model.

stately-common

This module has some expect/actual helpers around the freezing, mostly. I don't think there's much use for freeze() going forward, but I can make a reasonable case for ensureNeverFrozen(). If your code is getting frozen and you don't know why, you might want to have this available. Not sure it's enough of a use case to support a module, but its something I'm thinking about.

stately-concurrency

This module has atomics and locks. The new memory model does not have concurrency primitives that you could expect from the JVM, so there will certainly be a need for locks, and common-code atomics are useful too. This is territory that Atomic-fu currently addresses. However, Atomic-fu was for a while not really a public-facing library (although it was technically "public"). It is more public friendly now, but there may still be room for a "simple" version of concurrency primitives. This is a big decision I'd like to make soon and have some feedback on.

stately-isolate and stately-iso-collections

This is an interesting construct, and I think it has some value in edge cases, but it would not have been a library module if we didn't have to work around the strict memory model. Some people are using this, but I have to imagine after the new memory model is the default, people will stop. My current plan is that these definitely get archived.

Future features

I think we're going to need a concurrent collections API. I think we should consider building a simple one that wraps standard mutable collections with locks, then look into building something more robust later. By "robust" I mean smarter locking, or lockless, versions of collections. Better performance. Maybe less common structures (LRU cache?).