More radical ideas about gc and reference counting

[Jonathan M Davis via Digitalmars-d]

On Wed, 30 Apr 2014 13:21:33 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d at puremagic.com>
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).

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.

> 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.

> Also, we're considering a revamp of built-in slices, as follows.
> Slices of types without destructors stay as they are.
> 
> 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.
> 
> RCSlice!T will not convert implicitly to void[]. Explicit
> cast(void[]) will be allowed, and will ignore the reference count (so
> if a void[] extracted from a T[] via a cast outlives all slices,
> dangling pointers will ensue).
> 
> I foresee any number of theoretical and practical issues with this 
> approach. Let's discuss some of them here.

I'm really going to have to think about this one. It's such a radical
change that I really don't know what to think about it. It will be
interesting to see what others have to say about.

- Jonathan M Davis