q for touchlab folks: do you recommend disposing i...

# touchlab-tools

[saket]

q for touchlab folks: do you recommend disposing iso-collections to avoid memory leaks? I noticed this section under `stately-isolate`:

You must dispose of IsolateState instances to avoid memory leaks.

[russhwolf]

I'm not sure we expose an API to enable that. But maybe we should. I believe the thing you want to avoid leaking is the StableRef inside StateHolder, but I don't think any of the collections expose a way to clear it. Are you having specific issues or just looking for best practice? Kevin knows that stuff much better than me but he's on vacation.

[russhwolf]

Oops slack ate my link. This stableref: https://github.com/touchlab/Stately/blob/main/stately-isolate/src/nativeCommonMain/kotlin/co/touchlab/stately/isolate/Platform.kt#L13

[saket]

Are you having specific issues or just looking for best practice?

best practice! I've been using iso collections in my project but I never dispose them. I'm now thinking if that's something I should be doing.

this discussion originally started here where I'm trying to convince @evant to use iso collections in kotlin-inject: https://github.com/evant/kotlin-inject/issues/167#issuecomment-970449637

[russhwolf]

hm. It's a tough thing to invest a lot in right now with the new memory model on the horizon. One thing to watch out for: the new model still respects freeze() calls that exist in your code. So that's probably why you still see InvalidMutabilityException.

[russhwolf]

For possible workarounds take a look at https://github.com/JetBrains/kotlin/blob/master/kotlin-native/NEW_MM.md#unexpected-object-freezing

[russhwolf]

I don't know that I'd want to ship that yet though

[saket]

Yeah that's fair. I was under the impression that iso-collections are a drop-in solution.