DIP60: @nogc attribute

[via Digitalmars-d]

On Friday, 18 April 2014 at 14:15:00 UTC, Steven Schveighoffer 
wrote:
> 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.

In most situations where you need speed you do need to share data 
so that you can keep 8 threads busy without trashing the caches 
and getting the memory bus as a bottle neck.

Then you somehow have to tell the compiler what the mutex covers 
if ARC is going to be transparent… E.g. "this mutex covers all 
strings reachable from pointer P". So you need a meta level 
language…

> 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 don't know. I think one unified management strategy will not 
work in most real time apps. I think C++ got that right.

I also think you need both meta level reasoning (program 
verification constructs) and whole program analysis to get a 
performant solution with automatic management.

> 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.

As an addition to other management techniques, yes.