Safe reference counting cannot be implemented as a library

[Andrei Alexandrescu via Digitalmars-d]

On 11/1/15 5:52 PM, rsw0x wrote:
> On Sunday, 1 November 2015 at 22:36:46 UTC, Andrei Alexandrescu wrote:
>> On 11/01/2015 03:51 PM, Martin Nowak wrote:
>>> On 10/27/2015 01:27 PM, Andrei Alexandrescu wrote:
>>>> Unrelated, and a foreshadowing of the discussion on the lifetime
>>>> mailing
>>>> list: the compiler has ample opportunity to fuse incs/decs together, so
>>>> the signatures of these functions is:
>>>>
>>>> void opInc(uint delta);
>>>> void opDec(uint delta);
>>>
>>> Any hint/numbers showing that this is actually useful?
>>
>> Would be great to collect some, and generally get rigorous about the
>> whole approach.
>>
>>> Implementing such a cross statement optimization is quite some work. If
>>> this occurs often enough (in particular for shared classes with atomic
>>> ref counting) it might be worth the effort.
>>
>> Most reference counting techniques revolve around reducing mutation of
>> the reference count. See e.g.
>> https://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2012.pdf.
>>
>> So we need to show that many refcount updates take it from 1 to larger
>> than 1 and back. According to
>> https://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2012.pdf,
>> many objects have a reference count of just one; the "eclipse"
>> benchmark has 31.8% objects with a refcount greater than 1.
>>
>>
>> Andrei
>
> That paper is assuming that you take Java(a language that does *not*
> have allocation patterns like D such as favoring data on the stack,
> tightly packed arrays of data, and immutability) rip out its GC, and
> replace it with a RC-based GC with no concept of unique ownership - no?

The class objects we're focusing on for RC support are supposed to be 
used much like in Java. -- Andrei