https://kotlinlang.org logo
Join SlackCommunities
Powered by
Will it be possible to handle memory explicitly wi...
# kotlin-native
e
Will it be possible to handle memory explicitly with Kotlin Native?
m
enighma: I hope not.
e
@mg6maciej why is that?
m
Manual memory handling is known to be a cause of many bugs. Machines can do that better than us with ARC or GC.
e
That is correct, however in some performance sensitive scenarios you want to align and control your own memory. So having the ability, like you have in C# would be a win I think.
👍 2
s
That sounds like arguing against smart pointers.. Why? What specifically can you not do
m
Sometimes I really want to 
delete
an object before GC 🙂
e
@sreich There are many reasons why you’d wanna control memory explicitly. Cleaning up memory is a costly process and in a performance intensive application you want to control when it happens. Furthermore, I would also want to control how the memory is laid out so that I can maximize CPU cache hits.
^ Is very important for code running on multiple cores.
s
Those things are not mutually exclusive though. Smart pointers for instance only guard your pointers, you can decide when and how to allocate and free just fine. If you're writing for example, c++ without smart pointers..You're writing it wrong
And of course you can control how memory is laid out
Actually you can do that with Java too but only with primitives and things
I don't even think ARC has any restrictions on that..But I'm not privy on it
e
How would you do that in with java? Sure you can hold on to references but you have no control over when the actual GC happens. Not sure why we’re even talking about smart pointers. Because their existence does not change my initial question.
s
Cache coherency is possible in Java, using arrays. That's how it's done in c++ even. You can't ensure linear access unless you've a custom allocator, which is basically doing the same thing you'd do in Java for those sorts of things. But as I said, it's not as powerful. And you can't determine things like alignment and exact sizes aligning to cache lines
As @mg6maciej mentioned there is ARC
Which is basically smart pointers but more strictly enforced in the type system
Smart pointers you know exactly when anything will be freed. You also know this with ARC
You know exactly when the compiler will insert free calls because you are the one who tells it to
Not directly by calling free though. So, that's why it's misunderstood often as if there's some GC running in the background
plenty of non GC solutions for native code work infinitely better than raw pointers. If you're using raw pointers you're doing it wrong. I can't think of any valid situation where one could argue against smart pointers or ARC or things of that nature... Can you?
e
@sreich It’s kind of hard to reply when you post a plethora of responses, so maybe calm down? I think you have to understand that software development is not as black/white as you paints it to be. You might not understand why I asked the question and from my point of view it doesn’t look like you are interested in that either. You simply want to push your agenda of development, which is fine, but nothing I’m interested in discussing.
s
I am calm, just most people (mobile) reply often vs long. I don't have any agenda, I'm not sure what makes you think that. I've no stake in it one way or another. But you also didn't mention any tangible or quantifiable specifics. You kinda just hand waved it as "performance", I was asking for specifics, not to say you're wrong (because I could just as easily be) but because I'm genuinely interested to know
As I understood it, you were arguing against not being able to control memory manually for performances sake, which I agree with. But ARC and GC was mentioned. Unlike GC, ARC you do control memory directly and manually.. It's just more enforced (basically smart pointers on a smarter level)
m
I think there is one case that you want full control over addresses: when you access external device and need to set these and these bits. I didn't do that since studies and it was assembler...
s
So like I said, I'm interested if there's something specific about modern approaches to more safe memory management, that makes them unsuitable (smart pointers). Smart pointers actually don't incur any non negligible overhead and they've been recommended by c++ best practices for a few years now (got better with c++11). But really I'd just like to know what specifics are wrong with ARC
Hmm
That's still possible with c++ smart pointers
m
Ok. That invalidates what I said 🙂
s
Smart pointers are a way of gaining some type safety (it's c++ though so it isn't pretty like kotlin null safety), basically you create them and you can either describe it as "you own it(and will auto free when the last ref gets unused" or "someone else owns it". I've used them before with I.e. opengl, which is a C API and there are methods which give you a pointer to a buffer in the driver
They're pretty flexible, I'm not sure how flexible ARC is on this though, I only know a bit about it. It's only recently been beyond a "objective c" thing (swift got it)
Would be interesting to see further developments in that area though.. Further bridging the gap between super unsafe native and the unpredictably of gc
44 Views
Open in Slack
PreviousNext
Powered by