More radical ideas about gc and reference counting

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Wed Apr 30 15:48:15 PDT 2014


On 4/30/14, 3:08 PM, John Colvin wrote:
> 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.

An object starting as shared or immutable would always need to be 
atomically refcounted. That information is statically known. For those 
we'd initialize the refcount to 2.

An object starting as regular mutable would always be refcounted 
non-atomically. That's also known statically. So that constructor 
initializes the refcount to 1.

Then a const object would dynamically choose the approach to refcounting 
depending on the counter's evenness.


Andrei



More information about the Digitalmars-d mailing list