@gc attribute for bypassign @nogc

[Lodovico Giaretta via Digitalmars-d]

On Thursday, 28 July 2016 at 00:23:57 UTC, bitwise wrote:
> 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.

If @assumegc has to be manually checked to see if it is 
over-allocating whenever the application is going out of memory, 
then it is no more useful than running the gc-profiler when the 
application is over-allocating. The profiler is even better, 
because with @assumegc you have to check ALL marked functions to 
find the leaking one, while the gc-profiler would just put it on 
top of the report, making your job easier. So IMHO we already 
have an instrument to solve these problems.