@gc attribute for bypassign @nogc

[bitwise via Digitalmars-d]

On Wednesday, 27 July 2016 at 20:42:01 UTC, Guillaume Piolat 
wrote:
> On Sunday, 24 July 2016 at 22:13:02 UTC, bitwise wrote:
>>
>> There is the following, which is clever. But if it came down 
>> to having to do this to bypass @nogc, I simply wouldn't use 
>> @nogc.
>>
>> https://p0nce.github.io/d-idioms/#Bypassing-@nogc
>>
>> When you have to do it thousands of times throughout your 
>> codebase, then yes, it's that bad.
>>
>
> FWIW I've removed every use of that bypassing (was used for 
> runtime initialization or semaphores locks).
> You can also use emplace/destroy like in: 
> https://github.com/d-gamedev-team/gfm/blob/master/core/gfm/core/memory.d#L238

The point is though, that I WANT to use the GC. I want the memory 
cleaned up for me, and I don't mind little pauses once in a 
while. I just don't want careless allocations to happen in 
certain performance-sensitive contexts, like per-frame updates.

While working on a past project(C++), I found this little gem:

void draw() {
     Font* f = new Font("arial.ttf", 16);
     drawText(f, "hello world");
}

As utterly moronic as this seems, this was a real bug that I had 
to fix. Our game was literally topping out at 2GB of memory usage 
after ~30 seconds and crashing.

Note: it wasn't my code ;)

If that code was written in D with the feature I'm asking for, 
draw() would have been marked with @nogc. The person who wrote 
the above code would have either had to store the font somewhere 
else, or insert a @assumenogc{}  section to actually do that. So 
it either would not have happened, or would have been much easier 
to find.

If you found that your game/app was using too much GC, searching 
for "@assumenogc" would likely uncover the cause, as long as your 
root classes were annotated correctly. The @assumenogc annotation 
would plainly show where allocations were happening that maybe 
shouldn't be.

     Bit
     Bit