I have trouble understanding the Kotlin memory mod...

# multiplatform

[Stefan Oltmann]

I have trouble understanding the Kotlin memory model.

I get Uncaught Kotlin exception: kotlin.Throwable: The process was terminated due to the unhandled exception thrown in the coroutine [StandaloneCoroutine{Cancelling}@2929dd8, MainDispatcher]: mutation attempt of frozen kotlin.collections.HashMap@3b0368
if I do this:

val newPhotoSourceSyncInfo = mutableMapOf<PhotoSource, SyncInfo>()
newPhotoSourceSyncInfo.putAll(oldState.photoSourceSyncInfo)
newPhotoSourceSyncInfo[photoSource] = syncInfo

return oldState.copy(
    photoSourceSyncInfo = newPhotoSourceSyncInfo
)

But I can do this without any problem:

val newPhotoSources = mutableListOf<PhotoSource>()
newPhotoSources.addAll(oldState.photoSources)

newPhotoSources.add(
    PhotoSource(
        id = 1
    )
)

return oldState.copy(
    photoSources = newPhotoSources,
)

Why is that for a HashMap different and how can I do it to please the memory model?

[mkrussel]

I think the freeze rules do not apply to classes from Objective-C. I'm guessing that mutableMapOf delegates to NSDictionary, but HashMap is using a pure Kotlin class.

[Stefan Oltmann]

Do you mean mutableListOf ?

[mkrussel]

Id did. So I don't know the type of object returned by mutableMapOf, from the first example, but would have expected it to also be a native class that ignores freezing.

In general even if sample two works, I would avoid it and strictly follow the kotlin native memory model.

Assume any object accessible by multiple threads are frozen and do not modify them.

[Stefan Oltmann]

Ok, that sounds reasonable.

How would you change my code?

Some call that creates a new list plus that entry or what is the correct approach?

[mkrussel]

The snips are too small for me to see what is happening in different threads, what properties are accessible by multiple threads or what you are trying to do.

[Stefan Oltmann]

I just look up if there a one-shot commands in Kotlin that creates a new list/map with one added/removed entry without modifying one list

[Stefan Oltmann]

A, there is plus() . I try that

[Stefan Oltmann]

Ok, that did not help. Behind the scenes it does the same. I hoped somehow it has a native implementation that creates a new Collection without modifying a temporary one...

[Stefan Oltmann]

My app does it like the kmm-production-sample here:

https://github.com/Kotlin/kmm-production-sample/blob/29bb2c1240139922c4d060d6a53eb[…]mmonMain/kotlin/com/github/jetbrains/rssreader/app/FeedStore.kt

With List all is good, but Map does not work

[mkrussel]

Without studying the whole app, I would assume that addFeed is called on the main thread.

Ideally what you would want to do in your example, is get the new data from a background thread if needed and then update the map on the main thread. Try to leave mutable state on just the main thread.

If you do need to modify maps on multiple threads, you could look at the stately library.

[Stefan Oltmann]

Ok, thank you for your advice. I will see how I can change my code so that there is a better isolation.

[kpgalligan]

I think the freeze rules do not apply to classes from Objective-C.  I'm guessing that mutableMapOf delegates to NSDictionary, but HashMap is using a pure Kotlin class

mutableMapOf does not use NSDictionary

[kpgalligan]

I don't think so. NSDictionary is a map. mutableMapOf does not use that, though. It would be easier to figure this out with an example to run, and more detail from the stack trace. Exactly where is it getting upset?

[Stefan Oltmann]

Ok, understand.

[kpgalligan]

My guess is when copying from the original map, the internal try to optimize by reusing map entries or something like that, and that's where it fails.

[kpgalligan]

In fact, if it were using NSDictionary, you'd be avoiding this particular issue (but you'd be in danger of others).

[kpgalligan]

I do that to avoid freeze rules in a sqlite driver, but you need to be very careful with it.

[kpgalligan]

Anyway, this looks like it should work. If it's failing, I'd be interested in poking around a bit more (for context, I've discussed this a lot:

https://www.youtube.com/watch?v=oxQ6e1VeH4M▾

)

[Stefan Oltmann]

I have a coroutine running on Dispatchers.Default calling my method. This method launches a new Coroutine on Dispatchers.Main to manipulate this map and that's where it fails. Changing the external Coroutine to Main let's it work.

And yes, that may not be a List vs Map difference because I double-checked that indeed all List handling methods actually get called from Main coroutines. So that was my wrong assumption.

[Stefan Oltmann]

That's my current state of the method...

private fun onSyncStatusUpdate(
    oldState: PhotoState,
    photoSource: PhotoSource,
    syncInfo: SyncInfo
): PhotoState {

    print("onSyncStatusUpdate() method entry: ")
    logCurrentThread()

    launch(Dispatchers.Main) {

        print("onSyncStatusUpdate() launch block: ")
        logCurrentThread()

        val newPhotoSourceSyncInfo =
            oldState.photoSourceSyncInfo + (photoSource to syncInfo)

        // FIXME Use store.dispatch()
        state.value = oldState.copy(
            photoSourceSyncInfo = newPhotoSourceSyncInfo
        )
    }

    return oldState
}

[Stefan Oltmann]

So I'm not sure why this still fails because now the map modifying operation is on Main Thread... 🤷‍♂️

[Stefan Oltmann]

I will watch the linked youtube video and hope to understand all this better

[kpgalligan]

The video is a deep dive. I wrote this after the video as more of an overview: https://dev.to/touchlab/practical-kotlin-native-concurrency-ac7

[Stefan Oltmann]

Ok, thank you. I will read it and try to see where my thinking in wrong.

[kpgalligan]

If there's a way to get a failing repro that I can run somewhere, it would be a lot easier to figure out. In the meantime, I'd probably start with building the new map "the hard way", as in create a new mutable map and loop through each key/value of the old one, rather than "putAll" or oldState.photoSourceSyncInfo + (photoSource to syncInfo). If the code is failing on that line, I'd assume the map is trying to optimize something under the hood with a side effect that is incompatible with the freeze model. I'd also confirm it's exactly that and not somewhere else.

[kpgalligan]

I find the freeze model not too bad once you get used to it, but I have a very skewed perspective at this point. Also, some things are obvious, but some things are very difficult to spot, and occasionally they're extra weird.

[Stefan Oltmann]

Can a whole Map get frozen if I put a key into it that is frozen?

[Stefan Oltmann]

In your talk you said that it freezes "everything".

[kpgalligan]

Well, when you run freeze(), that will recursively freeze everything that the object is touching. If a key is already frozen, adding that to a map won't freeze the map.

[Stefan Oltmann]

@kpgalligan Do you know why a regular lambda freeze also freezes the implicit "this" and a Flow.collect() lambda does not? I think I don't quite understand the inner workings of that yet, so I'm a bit surprised about that.

https://kotlinlang.slack.com/archives/C3PQML5NU/p1636379868397700

[kpgalligan]

I've been getting multiple questions like this over the past 24 hours. Feels like I'm in an interview 🙂 I'll take a look...

[kpgalligan]

Long thread. If you have an update of the code as is, or something to run, it would be much easier to debug. Well, maybe not "much", but these issues can be difficult to reason in the abstract. I would put ensureNeverFrozen() on anything that shouldn't be frozen (and maybe leave it there). We do it proactively on certain types of objects (view models, etc)

[Stefan Oltmann]

We do it proactively on certain types of objects (view models, etc)

Yes, very good idea. After fixing multiple problems with accidently frozen state I now spam ensureNeverFrozen() all over the place for fail fast.