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