More radical ideas about gc and reference counting

[John Colvin via Digitalmars-d]

On Wednesday, 30 April 2014 at 21:51:17 UTC, Andrei Alexandrescu 
wrote:
> On 4/30/14, 2:47 PM, John Colvin wrote:
>> On Wednesday, 30 April 2014 at 20:57:26 UTC, Andrei 
>> Alexandrescu wrote:
>>>> 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.
>>
>> How? Having lock; instructions implicitly appearing in normal 
>> looking
>> slice code is unacceptable.
>
> I'm thinking e.g. non-interlocked refcounts go like 1, 3, 5, 
> ... and interlocked refcounts go like 2, 4, 6, ...
>
> Then you do an unprotected read of the refcount. If it's odd, 
> then it's impossible to having originated as an interlocked 
> one. So proceed with simple increment. If it's even, do an 
> interlocked increment.
>
>
> Andrei

I don't think I fully understand.

Either all RC changes for a given type need to be atomic or none 
do, and that information is given by the type (everything that is 
immutable/const/shared). I don't see any feasible way of escaping 
this, or any advantage to a runtime convention like the odd/even 
trick above.