DIP60: @nogc attribute

Steven Schveighoffer via Digitalmars-d digitalmars-d at puremagic.com
Fri Apr 18 07:15:00 PDT 2014


On Fri, 18 Apr 2014 10:00:21 -0400, Ola Fosheim Grøstad  
<ola.fosheim.grostad+dlang at gmail.com> wrote:

> On Friday, 18 April 2014 at 12:55:59 UTC, Steven Schveighoffer wrote:
>> The important thing to recognize is that it's the *caller* that  
>> increments/decrements. This means you can elide calls to an object  
>> where you already have a guarantee of its reference count being high  
>> enough.
>
> That won't help you if you iterate over an array, so you need a mutex on  
> the array in order to prevent inc/dec for every single object you  
> inspect.

If the array is shared, and the elements are references, yes. It's also  
possible that each object uses a reference to the array, in which case the  
array could be altered inside the method, requiring an inc/dec even for  
unshared arrays.

> inc/dec with a lock prefix could easily cost you 150-200 cycles.

And an inc/dec may not necessarily need a lock if the array element is not  
shared, even if you inc/dec the ref count.

D offers opportunities to go beyond traditional ref count eliding.

But even still, 150-200 extra cycles here and there is not as bad as a  
300ms pause to collect garbage for some apps.

I think nobody is arguing that Ref counting is a magic bullet to memory  
management. It fits some applications better than GC, that's all.

-Steve


More information about the Digitalmars-d mailing list