DIP60: @nogc attribute

[Orvid King via Digitalmars-d]

I'm just going to put my 2-cents into this discussion, it's my
personal opinion that while _allocations_ should be removed from
phobos wherever possible, replacing GC usage with manual calls to
malloc/free has no place in the standard library, as it's quite simply
a mess that is really not needed, and quite simply, one should be
figuring out how to simply not allocate at all rather than trying do
do manual management.

It is possible to implement a much better GC than what D currently
has, and I intend to do exactly that when I have the time needed (in
roughly a month). Firstly by making it heap precise, maybe even adding
a stack precise mode (unlikely). Secondly by making it optionally use
an allocation strategy similar to tcmalloc, which is able to avoid
using a global lock for most allocations, as an interim measure until
DMD gets full escape analysis, which, due to the nature of D, would be
required before I could implement an effective compacting GC.
Depending on if I can grasp the underlying theory behind it, I *may*
also create an async collection mode, but it will be interesting to
see how I am able to tie in the extensible scanning system (Andrei's
allocators) into it. Lastly, I'll add support for stack allocated
classes, however that will likely have to be disabled until DMD gets
full escape analysis. As a final note, this will be the 3rd GC I've
written, although it will be the most complex by far. The first was
just heap precise, the second a generational compacting version of it.

On 4/17/14, Manu via Digitalmars-d <digitalmars-d at puremagic.com> wrote:
> 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.
>