Re:Boehm-Demers-Weiser conservative C/C++ Garbage Collector
by pjmlp on Sunday January 21, 2024 @10:01AM
(#39079022)
The only deterministic thing is the call point, Herb points out that just like calling malloc()/free() it is not possible to deterministically assert the execution time, more so with complex data structures where not only there is a domino effect of destructors being called, there is also the possibility of causing stack overflows if the destuctors are written incorrectly, to build an argument for presenting his deferred pointer class, which is basically a GC in disguise.
[ Parent
| on HN ]
Re:Boehm-Demers-Weiser conservative C/C++ Garbage Collector
by jstimpfle on Sunday January 21, 2024 @10:51AM
(#39079499)
That is an obvious thing, and totally besides the point. Also, probably GC only helps little against this. Sure, actually calling the destructor can be delayed in order to even out latency. You can do the same with RAII.
Sometimes you can't do that though because you have certain constraints on the execution order of whatever routines you need to run. This is completely independent of whether you use manual cleanup or GC or RAII, however with GC it is weird/hard/impossible to synchronize the GC with the non-cleanup code.
Re:Boehm-Demers-Weiser conservative C/C++ Garbage Collector
by SleepyMyroslav on Monday January 22, 2024 @08:45AM
(#39089445)
I have anecdata to add to Herbs point.
I had a AAA project hitting 30ms pauses in free() implementation by platform vendor for quite popular gaming platform in 2016. Ofc it is anecdata but having actual deadlines from implementations is really hard. I had to replace malloc/free implementation like 3 month before ship date to avoid the issue.