 |
| “This debate has gone round and round for decades.” (comment) | ||
| recommended by 1 user | 2022 | shwestrick on: Reference count, don't garbage collect | language design | original thread | | ||
| shwestrick on Jul 29, 2022 | on: Reference count, don't garbage collect | view on HN | ||
| One user recommended this comment. What they said: |
|
mattgreenrocks Mar 9, 2023 | on: Getting Past “Ampersand-Driven Development” in Rust | context
Ref counting is considered GC (despite the colloquial definition excluding it) because RC handles the same problem domain as full GC, even with drawbacks around cycles. malloc/free, on the other hand, are just ways to allocate and release memory. They're too low level to be garbage collection. See this excellent comment: https://news.ycombinator.com/item?id=32277088 |
This debate has gone round and round for decades. There are no hard lines; this is about performance tradeoffs, and always will be.
Perhaps the biggest misconception about reference counting is that people believe it avoids GC pauses. That's not true. Essentially, whereas tracing GC has pauses while tracing live data, reference counting has pauses while tracing garbage.
Reference counting is really just another kind of GC. I'd highly recommend perusing this paper for more details: A Unifying Theory of Garbage Collection. https://web.eecs.umich.edu/~weimerw/2012-4610/reading/bacon-...
One of the biggest issues with reference counting, from a performance perspective, is that it turns reads into writes: if you read a heap-object out of a data structure, you have to increment the object's reference count. Modern memory architectures have much higher read bandwidth than write bandwidth, so reference counting typically has much lower throughput than tracing GC does.