6 days ago

On Saturday, 20 November 2021 at 13:48:44 UTC, JG wrote:

>

(a) specify exactly when the GC should do a stop the world mark and sweep (not when it feels like it when it needs to allocate memory and perhaps through an API more pleasant than the current, enable and disable mechanism);

GC.enable / GC.disable and manually provoking collections is only a quick fix.

The Right Way(tm) to go about it imho is to just have a smaller GC heap, that will reduce the maximum pause time (aka scanning) so that whatever happens your real-time system doesn't get encumbered by the GC.

How to get a small GC heap? With -profile=GC, pools, custom allocators, non-scannabled memory etc.
GC is actually pay as you go, the larger the heap the more you pay.
If you use very small amount of GC, disabling it or going -betterC will yield immeasurable gains, apart from memory usage.

Of course GC still doesn't work for fast callback that don't have the leisure to hold even a mutex, for those using deregistered thread and @nogc is necessary.

5 days ago

On Tuesday, 23 November 2021 at 14:02:34 UTC, Ola Fosheim Grøstad wrote:

>

On Tuesday, 23 November 2021 at 13:46:28 UTC, Imperatorn wrote:

>

I get the feeling that some ppl still believe the GC sneaks in some backdoor and says hello

The GC also has to scan non-GC memory if that memory can point back to GC-memory.

To be fair, it only does that if you explicitly register the non-GC memory with GC.addRoot. If you don't do this, GC memory can indeed be freed prematurely while still being referenced from non-GC memory.

5 days ago

On Wednesday, 24 November 2021 at 09:29:07 UTC, FeepingCreature wrote:

>

To be fair, it only does that if you explicitly register the non-GC memory with GC.addRoot. If you don't do this, GC memory can indeed be freed prematurely while still being referenced from non-GC memory.

GC.addRange, sorry.

5 days ago

On Wednesday, 24 November 2021 at 09:29:07 UTC, FeepingCreature wrote:

>

To be fair, it only does that if you explicitly register the non-GC memory with GC.addRoot. If you don't do this, GC memory can indeed be freed prematurely while still being referenced from non-GC memory.

Yes, this is the issue. You either have to make the GC scan non-GC memory or you have to do lifetimes "in your head". Neither are good options for large interactive programs. It can work for a tiny game though.

Next ›   Last »
1 2