RCArray is unsafe

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Tue Mar 3 13:37:20 PST 2015


On 3/3/15 12:35 PM, Zach the Mystic wrote:
> On Tuesday, 3 March 2015 at 18:48:36 UTC, Andrei Alexandrescu wrote:
>> On 3/3/15 9:00 AM, Zach the Mystic wrote:
>>> On Tuesday, 3 March 2015 at 16:31:07 UTC, Andrei Alexandrescu wrote:
>>>>> I was dazzed, but I'm not anymore. I wrote my concern here:
>>>>>
>>>>> http://forum.dlang.org/post/ylpaqhnuiczfgfpqjuww@forum.dlang.org
>>>>
>>>> There's a misunderstanding here. The object being assigned keeps a
>>>> trailing list of past values and defers their deallocation to
>>>> destruction. -- Andrei
>>>
>>> So you need an extra pointer per instance?
>>
>> Yah, or define your type to be single-assignment (probably an emerging
>> idiom). You can massage the extra pointer with other data thus
>> reducing its cost.
>>
>>> Isn't that a big price to
>>> pay? Is the only problem we're still trying to solve aliasing which is
>>> not recognized as such and therefore doesn't bump the refcounter like it
>>> should? An extra pointer would be overkill for that. Isn't it better to
>>> just recognize the aliasing when it happens?
>>
>> It's all tradeoffs. This has runtime overhead.
>
> Isn't allocating and collecting a freelist also overhead?

No. I don't have time now for a proof of concept and it seems everybody 
wants to hypothesize about code that doesn't exist instead of writing 
code and then discussing it.

>> A static analysis would have the challenges of being permissive
>> enough, cheap enough, not add notational overhead, etc. etc.
>
> It's certainly permissive: you can do anything, and compiler wraps
> uncertain operations with add/release cycles automatically. These are:
> passing a global as a mutable reference to an impure function; aliasing
> the same variable in two parameters with itself. The unoptimized
> lowerings would be:
>
> {
>    auto tmp = myGlobal; // bump count
>    impureFun(myGlobal);
> }  // tmp destroyed, --count
>
> {
>    auto tmp2 = c; // bump count
>    fun(c, c);
> } // --count
>
> The only addition is an optimization where the compiler elides the
> assignments and calls the add/release cycles directly.

Do you have something reviewable, or just your own past posts?

For the time being I want to move forward with DIP25 and deferred freeing.


Andrei



More information about the Digitalmars-d mailing list