4 ms·
> Reference counting is garbage collecting I am drawing a blank on google scholar at the moment, but I recall a very popular paper on exactly this topic of RC
by melissalobos 4y ago
> Reference counting is garbage collecting
I am drawing a blank on google scholar at the moment, but I recall a very popular paper on exactly this topic of RC as the other side of Tracing GC.
- hayley-patton 4y ago"A unified theory of garbage collection"? https://dl.acm.org/doi/10.1145/1028976.1028982 https://dl.acm.org/doi/10.1145/1028976.1028982
- melissalobos 4y agoYes! Thank you, I couldn't think of the terms to search for to find this.
- cmrdporcupine 4y agoNice, will put this paper in my bookmarks for later read. I feel like once you stop and think about it, the distinction between a 'tracing' GC and a 'non-tracing' GC is specious: To do its work at acquire and release, RC collector must in fact trace a tree of objects. It's just that the semantics of how this is declared might differ, or, more specifically the time(s) in which it does this work.
- hayley-patton 4y agoI think a fair part of the unified theory is that a tracing GC traces live objects, whereas a refcounting GC traces dead objects.
- cmrdporcupine 4y agoUpcounts trace live objects though. Just more incrementally.
- hayley-patton 4y agoBy "trace" I mean the act of consulting the state of an object, then recursively tracing pointers in the object. A tracing GC propagates a "known to be live" state through an object graph while doing a collection cycle, and a refcounting GC propagates a "known to be dead" state through an object graph, when RC drops to zero.
- hmlongco 4y agoUmm... but isn't the refcounting GC more deterministic? If I create a chain of 10 object and then release the head, I run through 10 allocations and then 10 release cycles on those 10 objects. Period.