DIP60: @nogc attribute

[Manu via Digitalmars-d]

On 17 April 2014 21:57, John Colvin via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On Thursday, 17 April 2014 at 11:31:52 UTC, Manu via Digitalmars-d wrote:
>
>> ARC offers a solution that is usable by all parties.
>>
>
> Is this a proven statement?
>
> If that paper is right then ARC with cycle management is in fact
> equivalent to Garbage Collection.
> Do we have evidence to the contrary?
>

People who care would go to the effort of manually marking weak references.
If you make a commitment to that in your software, you can eliminate the
backing GC. Turn it off, or don't even link it.
The backing GC is so that 'everyone else' would be unaffected by the shift.
They'd likely see an advantage too, in that the GC would have a lot less
work to do, since the ARC would clean up most of the memory (fall generally
in the realm you refer to below).


My very vague reasoning on the topic:
>
> Sophisticated GCs use various methods to avoid scanning the whole heap,
> and by doing so they in fact implement something equivalent to ARC, even if
> it doesn't appear that way on the surface. In the other direction, ARC ends
> up implementing a GC to deal with cycles. I.e.
>
> Easy work (normal data): A clever GC effectively implements ARC. ARC does
> what it says on the tin.
>
> Hard Work (i.e. cycles): Even a clever GC must be somewhat conservative*.
> ARC effectively implements a GC.
>
> *in the normal sense, not GC-jargon.
>
> Ergo they aren't really any different?


Nobody has proposed a 'sophisticated' GC for D. As far as I can tell, it's
considered impossible by the experts.
It also doesn't address the fundamental issue with the nature of a GC,
which is that it expects plenty of free memory. You can't use a GC in a
low-memory environment, no matter how it's designed. It allocates until it
can't, then spends a large amount of time re-capturing unreferenced memory.
As free memory decreases, this becomes more and more frequent.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140417/486212f0/attachment.html>