More radical ideas about gc and reference counting

[Andrei Alexandrescu via Digitalmars-d]

On 5/1/14, 7:30 AM, H. S. Teoh via Digitalmars-d wrote:
> On Thu, May 01, 2014 at 01:37:28AM -0700, Jonathan M Davis via Digitalmars-d wrote:
>> While it's not good to rely on finalizers, they're good to have as
>> backup if the appropriate cleanup function doesn't get called like
>> it's supposed to. They're not as critical as they'd be in Java, since
>> we have structs, but I'd be disinclined to remove finalizers from D
>> without a really good reason.
> [...]
>
> I'd like to hear an enumeration of those reasons as well.

1. Most scarce resources must be released eagerly. GC collections occur 
relatively rarely and are triggered by different signals (low on memory).

2. The notion of running the GC when one runs out of file handles or 
sockets is terribly inefficient.

3. Destructors are odd - they will run in a different thread than the 
one that created the object. They also are limited in surprising ways, 
i.e. may not allocate memory or block on other threads directly or 
indirectly.

4. Due to imprecision, there's no actual guarantee any given destructor 
will end up running. Leaving a scarce resources at the whim of a 
best-effort approach is poor design.

> While in principle I agree with the sentiment to get rid of class dtors,
> I'm concerned about the rippling side-effects this will have throughout
> the rest of the language. Such as class members that are structs with
> dtors, which will mean that the struct dtors will never get called.
>
> Using another poster's argument: if dtors are used for resource
> management, then it's a bad idea to mix dtors with GC (i.e. classes). So
> in this sense I agree with getting rid of class dtors. But we have to
> consider what happens to the case where you stick a struct with a dtor
> into a class. I'm inclined to say that we should outright prohibit that,

That can't happen.


Andrei