More radical ideas about gc and reference counting

[H. S. Teoh via Digitalmars-d]

On Thu, May 01, 2014 at 01:37:28AM -0700, Jonathan M Davis via Digitalmars-d wrote:
> On Wed, 30 Apr 2014 13:21:33 -0700
> Andrei Alexandrescu via Digitalmars-d <digitalmars-d at puremagic.com>
> wrote:
> 
[...]
> > First off, we're considering eliminating destructor calls from
> > within the GC entirely. It makes for a faster and better GC, but the
> > real reason here is that destructors are philosophically bankrupt in
> > a GC environment. I think there's no need to argue that in this
> > community.  The GC never guarantees calling destructors even today,
> > so this decision would be just a point in the definition space
> > (albeit an extreme one).
> 
> I really don't like the fact that struct destructors are not called by
> the GC, and if anything, I'd be inclined to argue for finding a way to
> guarantee that they get run rather than guaranteeing that they never
> get run. It's just far too easy to have a struct expect that its
> destructor will be run and then have issues when it's not run. But it
> would be better to define struct destructors as never getting run
> rather than having it be undefined as it is now.

+1.


> > We're considering deprecating ~this() for classes in the future.
> 
> 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.

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,
because again, the dtor (struct dtor this time) is used for resource
management, and therefore shouldn't be mixed with a GC'd resource (i.e.,
classes). I find it unacceptable that the compiler will silently accept
such a usage, and yet have no semantic guarantees (that dtor will run).
This is the kind of behaviour I expect from C/C++, but not from D.  Next
thing you know, somebody is gonna start wrapping structs inside classes
as a way of suppressing the dtor. I don't think that's the kind of thing
the language should allow. I contend that it will do the language a
great deal of good to outright ban such a kind of usage.

(Structs with no dtors, OTOH, can be safely used as class members,
obviously.)


T

-- 
It only takes one twig to burn down a forest.