More radical ideas about gc and reference counting

[deadalnix via Digitalmars-d]

On Wednesday, 30 April 2014 at 20:21:33 UTC, Andrei Alexandrescu 
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.
>

Still no consideration for isolated.

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

Not sure how I feel about that. This has been proposed as a 
solution to some GC issue at last DConf and has been dismissed. 
Your post is unclear on why this decision has changed. There must 
be some new information or data that inform this decision.

Or is it random ?

Also, what about cycle in RC things ? Also, RC is good on top of 
GC, so you can collect loop, especially if we are going to RC 
automagically. That is a major issue.

Finally, immutable is sharable accross thread. That mean, even if 
we bypass the type system, that RC must be atomic for immutable. 
As they convert automatically for co,st, that mean that all const 
code will be full of atomic increment/decrement. They are bad for 
the CPU, and cannot be optimized away.

That mean we are back to having a const and a mutable version of 
functions for performance reasons.

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

This won't work. array have a lot of magic that cannot be created 
as library. ie:

RCSlice!(const T) has nothing to do with const(RCSlice!T) as far 
as the compiler is concerned.

This is why we still don't have any library that provides 
collection properly. One of the best is probably dcollection, and 
it has no solution for that problem.

I'd like to see some core issue like that one before changing 
everything on top of it. When the whole thing is built on goo, 
readjusting the top to make it point upward is doomed to create 
the Pisa tower. Fine for tourists, but not very practical nor 
useful.