Any thoughts on an @gc attribute for bypassing @nogc?

As much as I like to cringe at the GC when I'm using C#, I can't ignore my level of productivity, as it compares to projects I've done in C++.

If I had to write a butter-smooth AAA game, it may be a problem, but at present, my thoughts on a few small jitters here and there are....who cares?

As long as GC usage is kept to a minimum, things will usually work ok fine.

For example, in a game, I may create a script with an "update" method that gets called each frame. I wouldn't want people(or myself) accidentally allocating memory here, possible 30-60 times per second, so I would  make that function @nogc. But, there *will* be cases where I actually want to allocate something, for example, to spawn a piece of cake.

Example:

class Cake{}

class MyScript {
    SysTime when;
    this() { when = Clock.currTime + 5.seconds; }
    void update() @nogc {
        // ...
        if(Clock.currTime >= when) {
            @gc {
                Cake c = new Cake();
            }
        }
    }
}

void main(string[] args) {
    MyScript script = new MyScript();

    foreach(i; 0..10) {
        script.update();
        Thread.sleep(1.seconds);
    }
}

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.

    Bit

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.

that's what i ended up with: not using @nogc. it is pure parketing thing. for real world using it adds more troubles than it ever solved (and did it solve at least something?!).

i'd say: "don't bother with @nogc, it is mostly useless."

pure *marketing* thing, lol.

On Sunday, 24 July 2016 at 22:13:02 UTC, bitwise wrote:
> Any thoughts on an @gc attribute for bypassing @nogc?
>
> As much as I like to cringe at the GC when I'm using C#, I can't ignore my level of productivity, as it compares to projects I've done in C++.
>
> If I had to write a butter-smooth AAA game, it may be a problem, but at present, my thoughts on a few small jitters here and there are....who cares?
>
> As long as GC usage is kept to a minimum, things will usually work ok fine.
>
> For example, in a game, I may create a script with an "update" method that gets called each frame. I wouldn't want people(or myself) accidentally allocating memory here, possible 30-60 times per second, so I would  make that function @nogc. But, there *will* be cases where I actually want to allocate something, for example, to spawn a piece of cake.
>
> Example:
>
> class Cake{}
>
> class MyScript {
>     SysTime when;
>     this() { when = Clock.currTime + 5.seconds; }
>     void update() @nogc {
>         // ...
>         if(Clock.currTime >= when) {
>             @gc {
>                 Cake c = new Cake();
>             }
>         }
>     }
> }
>
> void main(string[] args) {
>     MyScript script = new MyScript();
>
>     foreach(i; 0..10) {
>         script.update();
>         Thread.sleep(1.seconds);
>     }
> }
>
> 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.
>
>     Bit

In this kind of situation, the solution is to not use @nogc and use the built-in gc profiler to decide which functions need memory usage optimizations.
We should be very careful, that using @nogc is not the aim. It is just one of the available tools to avoid our application randomly freezing due to collections. That is the aim. And there are other tools to achieve it: the allocators library and the built-in gc profiler.

@nogc functions must never ever trigger GC collection cycle, not under any possible circumstances. Otherwise the attribute serves no purpose.

On Sunday, 24 July 2016 at 22:21:51 UTC, ketmar 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.
>
> that's what i ended up with: not using @nogc. it is pure parketing thing. for real world using it adds more troubles than it ever solved (and did it solve at least something?!).
>
> i'd say: "don't bother with @nogc, it is mostly useless."

I don't understand what you mean, saying it's useless.

I intend to do this:

class Script {
    @nogc void update(){}
}

class CustomScript : Script {
    override void update(){}
}

If I did this, it would act as a safety net, and prevent a lot of accidental allocations. Keep in mind, "update" is meant to run 30-60 times per second, so allocations would add up extremely fast.

    Bit

On Sunday, 24 July 2016 at 23:14:37 UTC, bitwise wrote:
> I don't understand what you mean, saying it's useless.

exactly that. in the end i can't mark any code @nogc except very trivial, where it doesn't matter at all (primitive getters and setters). in other code i ocasionally need to allocate or throw. so you have to ditch @nogc anyway.

and yes, i'm talking about engines that should maintain solid 60 FPS.

and for "safety nets" i prefer to use "-vgc" after i done some amount of work to see if i accidentally missed something.

On Sunday, 24 July 2016 at 23:10:18 UTC, Dicebot wrote:
> @nogc functions must never ever trigger GC collection cycle, not under any possible circumstances. Otherwise the attribute serves no purpose.

The fact that you can use malloc() in a @nogc function invalidates this argument. There are many ways for someone publishing a piece of code or DUB package to be irresponsible about memory management. Adding this would not make it any more likely. Adding @gc to a piece of code to bypass @nogc is not something that could be done by accident.

Imagine though, if there was a DUB package that provided some base class that had its virtual methods annotated with @nogc. If I downloaded the package, and decided that using GC was perfectly fine in my application, I would be screwed if I wanted to inherit one of the classes from that package.

    Bit

On Sunday, 24 July 2016 at 23:30:37 UTC, bitwise wrote:
> On Sunday, 24 July 2016 at 23:10:18 UTC, Dicebot wrote:
>> @nogc functions must never ever trigger GC collection cycle, not under any possible circumstances. Otherwise the attribute serves no purpose.
>
> The fact that you can use malloc() in a @nogc function invalidates this argument.

malloc is not even on the same order of magnitude of impact as GC. @nogc is primarily about latency and preventing unwanted stop the world cycle, not about performance or allocation count per se.

On Sunday, 24 July 2016 at 23:30:37 UTC, bitwise wrote:
> On Sunday, 24 July 2016 at 23:10:18 UTC, Dicebot wrote:
>> @nogc functions must never ever trigger GC collection cycle, not under any possible circumstances. Otherwise the attribute serves no purpose.
>
> The fact that you can use malloc() in a @nogc function invalidates this argument.

nope. `malloc()` has nothing to do with garbage collection.

what `@nogc` means is "i won't use built-in allocator with garbage collection in this code", not "i won't do any memory allocations in this code".