What's this? <https://github.com/JetBrains/kotlin-...

# kotlin-native

[Dominaezzz]

What's this? https://github.com/JetBrains/kotlin-native/blob/45914cf4eccc67f790494688fe3c5f449736ed2e/runtime/src/main/cpp/Memory.cpp#L1091 If I hit this, have I leaked memory or.....?

[kpgalligan]

It’s in decrement, so I would guess this is because ref counts aren’t atomic for non-frozen data, and in the context of what we’ve been talking about, I assume something mutable isn’t 100% detached when transferred.

[Dominaezzz]

Hmm, but I freeze everything before insertion. Unless.... it's the StableRef object itself.

[kpgalligan]

This is why I avoid unsafe. Tricky stuff. I don’t know off hand what the issue would be, but something’s not right. Can be very difficult to sort out. I’ve lost many hours playing that game.

[Dominaezzz]

I reproduced it on Linux.

[Dominaezzz]

It just runs different everytime. (sigh).

[kpgalligan]

Yeah. Race conditions!

[Dominaezzz]

Oops, wrong thread.

[Dominaezzz]

Hahaha.

[kpgalligan]

Oh, well, comment still worked

[Dominaezzz]

Ah, I changed transfer to SAFE and all the tests broke. Making progress, should have tried that first.

[Sam Schilling]

I have had this same error show up inconsistently when I was using TransferMode.UNSAFE . My program would crash at random times with it while doing background thread work.

[Dominaezzz]

Okay, the single threaded now breaks even for SAFE. I'm gonna call it quits before the tears come in.

[kpgalligan]

Yes. You should never use unsafe. “My program would crash at random times with it while doing background thread work” You will get race conditions with memory management using unsafe.

[kpgalligan]

@Dominaezzz Curious about issues with safe, but for another day

[Sam Schilling]

Yeah, we had to switch to safe mode since unsafe was behaving so unreliably.

[Dominaezzz]

I made the mistake of using UNSAFE before testing with SAFE. I have faith in the DetachedMutableMap . I just need to figure out the single-threaded issue.

[Dominaezzz]

Maybe I just haven't experienced enough pain to learn my place. 😆

[kpgalligan]

DetachedMutableMap works, it’s just not that useful in practice (in my experience). No idea what’s up with your safe issue, though

[Dominaezzz]

Really, I thought it would be nice for global cache or something....

[kpgalligan]

Well, that’s what the blog post was about. Global cache is faster and easier keeping state in a single thread. By `DetachedMutableMap`I meant DetachedObjectGraph. Just copy/pasted. Anyway, I thought so too originally, but we just never use it. Stately’s shared collections with atomics “work”, but I’ve been meaning to rewrite them for a while. Keeping state by itself in a single thread is easier to deal with. For people that dislike the KN state model, keeping state in a separate thread will be another argument against it, but so far it’s working great. Hopefully will release a stately update next week-ish

[Arkadii Ivanov]

I'm wondering for what reason we have UNSAFE? Are there any real use cases?

[kpgalligan]

I haven’t had many. None that I can currently think of. I was just typing out a long one and realized that was a bad idea.

[Arkadii Ivanov]

Same for me, hmmm

[kpgalligan]

Hmm, OK. Maybe this. An Array of some type. All values in it are frozen, but the Array itself isn’t. You always keep a ref in one thread, then share it unsafe to a worker (but, critically, always the same worker). Nah. Even then you’re asking for problems. Don’t have any. Looking through kotlin native source to see if it’s being used anywhere, but haven’t found any so far.

[kpgalligan]

I was thinking there’d be something in the internals of kotlin native’s runtime, but there’s nothing

[kpgalligan]

No idea. I’ve run into odd issues where there’s some data getting held somewhere else.

[Dominaezzz]

Brilliant, this is quite painful. That is why the tests broke. I reckon it's the cached iterator, somehow. I'll just create a new map for now.

[Dominaezzz]

Even simpler.

val umm = DetachedObjectGraph {
    val map = mutableMapOf<String, String>()
    for (entry in map.entries) {
        // Do nothing.
    }
    map
} // kotlin.IllegalStateException: Illegal transfer state
println(umm.attach())

[Dominaezzz]

https://github.com/JetBrains/kotlin-native/issues/3801

[Kavan]

Mutable can't processed in detached, I tested all immutable works file.I think because of DetachedObjectGraph creates stable pointer to object.

[Dominaezzz]

Processed?

[Kavan]

Use *SorryForBadEnglish

[Kavan]

I mostly avoid use of mutable when it converting to C pointer.

[Kavan]

Somewhere I heard detachedobjectgraph detach it from main thread. Not 100% sure

[Dominaezzz]

But all maps are pretty much mutable.

[Kavan]

mapOf<String, String>() or hashMapOf are non mutable

[Dominaezzz]

Sure, they return Map<String, String> interface, but they are just a cast away from being `MutableMap`s in the end. (Unless you're talking about EmptyMap but that's not very useful here) .

[Kavan]

I'm also facing many limitations of using kotlin mutables with C introp. So I ended not to use.