More radical ideas about gc and reference counting

John Colvin via Digitalmars-d digitalmars-d at puremagic.com
Thu May 1 02:42:36 PDT 2014


On Wednesday, 30 April 2014 at 22:48:28 UTC, Andrei Alexandrescu 
wrote:
> 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

Ah ok, that makes sense.


More information about the Digitalmars-d mailing list