Why many programmers don't like GC?

Ola Fosheim Grøstad ola.fosheim.grostad at gmail.com
Fri Jan 15 16:37:46 UTC 2021


On Friday, 15 January 2021 at 16:26:59 UTC, Guillaume Piolat 
wrote:
>> 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.

But when do you call collect? Do you not create more and more 
long-lived objects?

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

How do you structure this? Limit GC to one main thread? But an 
audio plugin GUI is not used frequently, so... hickups are less 
noticable. For a 3D or animation editor hickups would be very 
annoying.

> The pain point with the mixed approach is adding GC roots when 
> needed. You need a mental model of traceability.

Yes. I tend to regret "clever" solutions when getting back to the 
code months later because the mental model is no longer easily 
available.

I think it is better with something simpler like saying one GC 
per thread, or ARC across the board unless you use non-arc 
pointers, or that only class objects are GC. Basically something 
that creates a simple mental model.

> It really is quite easy to do: build you app normally, 
> evetually optimize later by using manual memory management.

I understand what you are saying, but it isn't all that much more 
work to use explicit ownership if all the libraries have support 
for it.

It is a lot more work to add manual memory management if the 
available libraries don't help you out.




More information about the Digitalmars-d-learn mailing list