https://kotlinlang.org logo
Join Slack
Powered by
Totally out of my depth in native land, so please ...
# kotlin-native
a
Totally out of my depth in native land, so please do forgive me if this comes out as a straight forward question. Does the new memory model place us at a position to no longer use 
memScope
?
b
No, it just lets you turn off your freezer
😆 1
MemScope is still very much needed for native calls
💯 1
➕ 1
👍 1
e
I'm not sure why you would think that it could
b
He's just getting his feet wet in konan, plus both refer to memory in different ways
e
the memory allocation and placement that takes place within a 
memScoped
cannot be tracked by the Kotlin object graph, so the scope is there to ensure orderly cleanup
👍 1
a
understood. Somehow, I got the intuition that the objects can be easily grabbed by the garbage collector that comes with the new mm
b
That's true, but only for kotlin managed objects that live in kotlin domain. i.e. are not used by external c libraries or processes
👍 1
Otherwise kotlin could collect memory which is no longer used by your kotlin code, but might still be in use by some system/c process
memScoped basically tells kotlin compiler that any allocated memory within that scope will no longer be used when it exits
New mm just allows you to pass mutable data between kotlin managed threads without freezing. In single-threaded applications the change is literally invisible.
a
but might still be in use by some system/c process
That irons it our perfectly. Thanks a lot
l
I had a really annoying bug once when I created a Kotlin/Native object by constructor instead of alloc in some arena or memscope, then passed it to a C library. K/N saw that the variable was no longer used by it, so it gc’ed the variable. C didn’t know this, however, so it was still writing to the memory. Occasionally, K/N would allocate a new Kotlin object over this same spot, leading to crashes.
e
depending on your use case, 
.usePinned()
might have helped
👍 1
a
That must have been a hair pulling experience. With this info, I am going back to the kotlin native documentation
l
If I recall correctly, the C library needed the memory for long periods of time, and usePinned un-pins when the lambda completes if I understand it right. Either way, I was using a Kotlin ByteArray with refTo when I needed a byte*, so I was probably doing something wrong anyways. I changed it to allocate a byte array using an arena, and it’s worked fine since.
e
yeah, at that point you're doing manual memory management just like C, but sometimes that's required to work with C APIs
l
While I do like the concept of arenas, I will admit that I wish there were some equivalent to free for a single manually managed variable. I usually keep a 
tempArena
for this reason, that I set aside for specific variables that by implicit contract can be freed any time without problem. It would be nice to have some other arena equivalent that lets me alloc and free individual variables.
I guess I could cinterop malloc and free on the system at that point, though.
e
Copy code
val ptr = nativeHeap.alloc(...)
nativeHeap.free(ptr)
l
I didn’t know about nativeHeap. Is this available everywhere in K/N?
👌 1
e
l
Thanks. I’ll look into it.
5 Views
Open in Slack
PreviousNext
Powered by