Safe reference counting cannot be implemented as a library

[rsw0x via Digitalmars-d]

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?