More radical ideas about gc and reference counting

[Benjamin Thaut via Digitalmars-d]

Am 30.04.2014 22:21, schrieb Andrei Alexandrescu:
> 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).
>
> 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.
>
> 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.
>
>
> Thanks,
>
> Andrei

Honestly, that sounds like the entierly wrong apporach to me. Your 
approaching the problem in this way:

"We can not implement a propper GC in D because the language design 
prevents us from doing so. So lets remove destructors to migate the 
issue of false pointers."

While the approach should be.

"The language does not allow to implement a propper GC (anything else 
then dirty mark & sweep), what needs to be changed to allow a 
implementation of a more sophisticated GC."

Also let me tell you that at work we have a large C# codebase which 
heavily relies on resource management. So basically every class in there 
inherits from C#'s IDisposable interface which is used to manually call 
the finalizer on the class (but the C# GC will also call that 
finalizer!). Basically the entire codebase feels like manual memory 
management. You have to think about manually destroying every class and 
the entire advantage of having a GC, e.g. not having to think about 
memory management and thus beeing more productive, vanished. It really 
feels like writing C++ with C# syntax. Do we really want that for D?

And what if I want unsafe slices of structs with destructors, for 
performance? Maybe I perfectly know that the memory behind the slice 
will outlive the slice, and I don't want the overhead of all the 
reference counthing behind it?

If you actually deprecate ~this, there would be two options for me.
1) Migrate my entire codebase to some user defiend finalizer function 
(which doesn't have compiler support), which would be a lot of work.
2) Quit D. (which is becomeing more and more an option when reading the 
recent news group discussions.)

-- 
Kind Regards
Benjamin Thaut