Future of memory management in D
Stanislav Blinov
stanislav.blinov at gmail.com
Wed Nov 17 07:08:45 UTC 2021
On Wednesday, 17 November 2021 at 02:32:21 UTC, H. S. Teoh wrote:
> And you know what? In spite of all this time and effort,
> programmers get it wrong anyway -- typical C code is full of
> memory leaks, pointer bugs, and buffer overflows.
People write bugs. You don't say!
> Most of them are latent and only trigger in obscure
> environments and unusual inputs, and so lie undiscovered,
> waiting for the day it suddenly explodes on a customer's
> production environment.
GC isn't solving those issues. It's masking them. If you have a
stale pointer somewhere, the bug *is* that the pointer is stale.
Making it point to some forgotten piece of data is not a
solution, it's a write off of a lost cause. Yeah, it's @safe,
sure. Because you're leaking.
> Or somebody comes up with a security exploit...
Your susceptibility to security (and other) exploits grows
proportional to the number of dependencies, of which druntime
(and, consequently, GC) is one. So that's kind of a moot point.
> With a GC, you instantly eliminate 90% of these problems. Only
> 10% of the time, you actually need to manually manage memory --
> in inner loops and hot paths where it actually matters.
It's so funny how you keep talking about this mythical 90% vs 10%
split. When you have 16ms *for everything*, and a single
collection takes 8ms, during which the whole world is stopped,
you can't have 90/10. When you can't actually disable the GC (and
you can't *actually* disable the GC), you can't have 90/10,
because eventually some forced collection *will* turn that 90
into 99. So, practically, it comes down to either you use the GC,
or you don't, period. That is not the fault of GC per se, but
it's the consequence of lack of control. Unfortunately, price of
convenience sometimes is just too high.
> GC phobia is completely irrational and I don't see why we
> should bend over backwards to please that crowd.
Simply put? Because any decent API doesn't transfer its garbage
to its callers. And because, surprise, sometimes deterministic
run time is a requirement. If the cost of calling your function
is 100 cycles now and a million at some poorly specified point in
the future, I'd consider looking for something that would just
take the million up front.
More information about the Digitalmars-d
mailing list