Can `AtomicRef` (common version) leak memory like `AtomicReference` (native version)? And if so, how...

# kotlin-native

[Lulu]

Can AtomicRef (common version) leak memory like AtomicReference (native version)? And if so, how to avoid memory leak given that I write code in common?

[natpryce]

Clear the reference to null when you no longer need the referenced object.

[Lulu]

Got it. Btw can references be shared between threads without being frozen? Still talking about writing code in common.

[Prateek Grover]

As far as I have seen, in both AtomicRef and AtomicReference, the value stored inside references are themselves frozen. So yes, refs can be shared among threads without being frozen, but since the values are frozen, you can't mutate them. You will be able to update the value though.

[Lulu]

Interesting. What I'm going to store in AtomicRef is an object that contains a Long (immutable) and an AtomicInt. There won't be issues regarding the AtomicInt right? (i.e. I can change it as normal)

[Prateek Grover]

I havent tried it yet, but I dnt think it will be a problem. Although I read about FreezableAtomicReferences being used in AtomicFu library for AtomicReferences

[kpgalligan]

AtomicInt is fine. “refs can be shared among threads without being frozen” Technically not correct. The AtomicRef is frozen, but there’s magic under the hood to let you change the value. All versions of AtomicRef in native need to be nulled out to ensure GC. That may change, though.

[Lulu]

Thank you all

[Prateek Grover]

"refs can be shared among threads without being frozen Technically not correct" . Can you please elaborate Kevin?

Thanks

[kpgalligan]

The AtomicReference class itself is frozen. By that I mean ref.isFrozen will return true. However, you can still change the value it holds. So, it’s “frozen” but “mutable”.

[Prateek Grover]

and what magic is that, that it is able to still modify?

[kpgalligan]

https://github.com/JetBrains/kotlin-native/blob/cae31c7853e20f2bc34015289c97ccb1f931b8fd/runtime/src/main/kotlin/kotlin/native/concurrent/Atomics.kt#L225

[kpgalligan]

https://github.com/JetBrains/kotlin-native/blob/81eb6b2be689591b4bd697464c910afdc0f2a456/runtime/src/main/cpp/Atomic.cpp#L199

[kpgalligan]

public class AtomicReference<T>(private var value_: T) {
    // A spinlock to fix potential ARC race.
    private var lock: Int = 0

[kpgalligan]

Internally, each piece of data is just a C++ field. That’s value_ and lock

[kpgalligan]

void Kotlin_AtomicReference_set(KRef thiz, KRef newValue) {
    Kotlin_AtomicReference_checkIfFrozen(newValue);
    AtomicReferenceLayout* ref = asAtomicReference(thiz);
    SetHeapRefLocked(&ref->value_, newValue, &ref->lock_);
}

[kpgalligan]

The value is changed in the C++ level, which bypasses the normal frozen mutability check.

[Prateek Grover]

Got that. I saw one of your talks in which you mentioned that the freeze happens at memory level. What did you mean by that? Does it mean that freeze happens at the level of Kotlin Runtime memory access? and since everything is a c++ pointer if you go to that level and we can just play around with those like normal c++ pointers

[Prateek Grover]

and the way it changed a frozen object, let's say I implement a similar functionality by going to C++ level, will I be able to change anything myself (assuming my impl is correct)?

[kpgalligan]

Frozen is a runtime flag on the object header. https://github.com/JetBrains/kotlin-native/blob/919db81fba64450aaf86735cfaced4c0dcff2f41/runtime/src/main/cpp/Memory.h#L96-L96

[kpgalligan]

You can do whatever you want in C++, but I would HIGHLY suggest avoiding it unless you are in extremely odd circumstances

[kpgalligan]

I lost weeks of my life in 2017 trying to work around some of the concurrency rules in KN. All I accomplished was creating race conditions

[Prateek Grover]

Understood. Thanks kevin for patiently answering the queries. You are really a great help in understanding the depth of KN.