Why does D rely on a GC?

[Marco Leise via Digitalmars-d]

Am Tue, 19 Aug 2014 07:23:33 +0000
schrieb "Kagamin" <spam at here.lot>:

> >  With GC you give up deterministic behavior, which is 
> > *absolutely* not worth giving up for 1% of objects.
> 
> Memory needs deterministic management only under condition of 
> memory scarcity, but it's not a common case, and D allows manual 
> memory management, but why force it on everyone because only 
> someone needs it?

Don't dismiss his point easily. The real memory cost is not
always visible. Take for example bindings to GUI libraries
where bitmap objects left to be garbage collected may have a
16 byte wrapper object, but several megabytes of memory
associated with it inside a C library. The GC wont see the
need to run a sweep and the working set blows out of
proportion. (Happened to me a few years ago.)
Other times you may just run out of handles because the GC is
not called for a while.

In practice you then add .close/.release methods to every
resource object: and here we are back at malloc/free. Cycles
aside, reference counting does a better job here.
In other words, a GC cannot handle anything outside of the
runtime it was written for, in short: OS handles and
foreign language library data structures.

-- 
Marco