More radical ideas about gc and reference counting

[Andrei Alexandrescu via Digitalmars-d]

On 4/30/14, 1:46 PM, deadalnix wrote:
> On Wednesday, 30 April 2014 at 20:21:33 UTC, Andrei Alexandrescu wrote:
>> 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.

"Ecstatic" is what you're looking for.

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

I don't remember a proposal being made that made slices of structs with 
destructors distinct from other slices.

> Also, what about cycle in RC things?

Resource leaks may happen in programs in any language. I'm prepared to 
allow leaks in certain cases, and I posit here that such cases are rare 
(arrays of objects that embed references to the very array they're in).

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

That stays, and it's useful. I'm talking destructors here.

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

Good point. I see that as a problem, albeit a solvable one.

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

I don't think that's the case. We could and should be able to only use 
refcounting for truly immutable slices. (Using a bit in the counter to 
indicate sharing comes to mind.)

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

We need to improve the language to allow for such. Did I mention it's 
not going to be easy?


Andrei