DIP60: @nogc attribute

Orvid King via Digitalmars-d digitalmars-d at puremagic.com
Thu Apr 17 06:56:10 PDT 2014


I should probably have said heap allocation rather than just
allocation, because the alloca calls are the ones that would have the
real benefit, those realtime applications are the reason I hope to be
able to implement an async collection mode. If I were able to
implement even a moderately compacting GC, I would be able to use a
bump-the-pointer allocation strategy, which would be significantly
faster than manual calls to malloc/free.

On 4/17/14, Regan Heath via Digitalmars-d <digitalmars-d at puremagic.com> wrote:
> On Thu, 17 Apr 2014 14:08:29 +0100, Orvid King via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>
>> 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.
>
> The standard library is a better place to put manual memory management
> than user space because it should be done by experts, peer reviewed and
> then would benefit everyone at no extra cost.
>
> There are likely a number of smaller GC allocations which could be
> replaced by calls to alloca, simultaneously improving performance and
> avoiding GC interaction.
>
> These calls could then be marked @nogc and used in the realtime sections
> of applications without fear of collections stopping the world.
>
> Neither ARC nor a super amazing GC would be able to improve upon the
> efficiency of this sort of change.
>
> Seems like win-win-win to me.
>
>> 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).
>
> Excellent :)
>
> R
>


More information about the Digitalmars-d mailing list