On Friday, 15 January 2021 at 16:21:18 UTC, Ola Fosheim Grøstad
wrote:
What do you mean by "mix and match"? If it means shutting down
the GC after initialization then it can easily backfire for
more complicated software that accidentally calls code that
relies on the GC.
I mean: "using GC, unless where it creates problems". Examples
below.
Until someone can describe a strategy that works for a full
application, e.g. an animation-editor or something like that,
it is really difficult to understand what is meant by it.
Personal examples:
- The game Vibrant uses GC for some long-lived objects.
Memory pools for most game entities.
Audio thread has disabled GC.
- Dplug plugins before runtime removal used GC in the UI, but no
GC in whatever was called repeatedly, leading to no GC pause in
practice. In case an error was made, it would be a GC pause, but
not a leak.
The pain point with the mixed approach is adding GC roots when
needed. You need a mental model of traceability.
It really is quite easy to do: build you app normally, evetually
optimize later by using manual memory management.
