News for hackers. Stuff that matters.
Re:Reference count, don't garbage collect by waterhouse on Friday July 29, 2022 @06:20PM (#32282423)
> Essentially, whereas tracing GC has pauses while tracing live data, reference counting has pauses while tracing garbage.

This is pretty trivial to avoid. When your thread finds itself freeing a big chain of garbage objects, you can have it stop at any arbitrary point and resume normal work, and find some way to schedule the work of freeing the rest of the chain (e.g. on another thread). It's much more complex and expensive to do this for tracing live data, because then you need to manage the scenario where the user program is modifying the graph of live objects while the GC is tracing it, using a write or read barrier; whereas for garbage, by definition you know the user can't touch the data, so a simple list of "objects to be freed" suffices.

"Reads become writes" (indeed, they become atomic read-modify-writes when multiple threads might be refcounting simultaneously) is a problem, though.

Re:Reference count, don't garbage collect by kaba0 on Friday July 29, 2022 @07:01PM (#32282667)
> It's much more complex and expensive to do this for tracing live data

But this is what happens in a modern state-of-the-art tracing GC implementation, isn't it?

Re:Reference count, don't garbage collect by pjmlp on Saturday July 30, 2022 @04:11AM (#32285172)
And so it becomes a simple tracing GC implementation, while one keeps calling it RC to feel good.