More radical ideas about gc and reference counting

[Steven Schveighoffer via Digitalmars-d]

On Wed, 30 Apr 2014 16:21:33 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Walter and I have had a long chat in which we figured our current  
> offering of abstractions could be improved. Here are some thoughts.  
> There's a lot of work ahead of us on that and I wanted to make sure  
> we're getting full community buy-in and backup.
>
> 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).

destructors are for cleaning up non-GC resources. File handles, malloc'd  
memory, etc. I don't see why these need to be eliminated.

What about changing destructors so that they DON'T implicitly call member  
struct dtors? I'd prefer that, since struct dtors executed on the heap I  
agree are an issue. One can always call the dtor in the class dtor if  
necessary. Right now, you have no choice.

> That means classes that need cleanup (either directly or by having  
> fields that are structs with destructors) would need to garner that by  
> other means, such as reference counting or manual. We're considering  
> deprecating ~this() for classes in the future.

So essentially, any class with a dtor needs reference counting? How does  
one clean up a cycle of them?

> Slices T[] of structs with destructors shall be silently lowered into  
> RCSlice!T, defined inside object.d. That type would occupy THREE words,  
> one of which being a pointer to a reference count. That type would  
> redefine all slice primitives to update the reference count accordingly.

This is a possibility, but I think you would need to prove performance is  
not severely affected.

> I foresee any number of theoretical and practical issues with this  
> approach. Let's discuss some of them here.

I'd rather see a RC array type, which specifically supports reference  
counting for opt-in support.

But we are getting WAY ahead of ourselves. A workable RC solution has to  
be proven first. I'd feel much more comfortable making such a change with  
a working, tested solution to look at.

-Steve