Permalink
Reply
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.
