4 ms·

> Rust also uses a GC, just a particularly primitive one -- reference counting This meme that reference counting and garbage collection are even remotely the s

> Rust also uses a GC, just a particularly primitive one -- reference counting This meme that reference counting and garbage collection are even remotely the same needs to die in a fire. Reference counting is not, and never has been, "primitive garbage collection", and garbage collection is not, and never has been, "super sophisticated reference counting".

earenndil 7y ago
Garbage collection means a way to automatically collect garbage. Reference counts automatically collect garbage. Therefore reference counting is a subset of garbage collection.
- erichocean 7y ago
  > Reference counts automatically collect garbage. Reference counts are used to manage resources, one of which is memory (and I'm assuming you are referring to no-longer-referenced memory as "garbage"). But that's not the only use for reference counts! You can, and should, use reference counts for external resources, such as files, or memory buffers on a GPU, or…. Garbage collection is COMPLETELY USELESS for managing non-memory resources because you need to be able to deterministically release non-memory resources (and oftentimes, memory resources—e.g., on the GPU). And since all a GC can do is examine memory, well, it doesn't work. Go ahead: point me to a 3D game engine using garbage collection for GPU resources. I'll wait. So yeah: "reference counting is a subset of garbage collection" is absolutely not true, and even the most basic knowledge of how reference counting is used in practice should be enough to convince anyone of that. Again: this meme needs to die. Garbage collection is not "super sophisticated reference counting", and in fact, can't even be used in most places where reference counting is used. It's not a substitution, or a superset, of reference counting. GC is a compelling alternative to reference counting for resources just in the main memory heap in some situations where performance (esp. total memory usage) isn't an important concern relative to, say, programmer productivity.
  - erik_seaberg 7y ago
    You can close a non-memory resource when an object that owns it becomes garbage (Java calls this a "finalizer"), it's just not common. Those resources tend to be too expensive to leave unused indefinitely, and explicit closing risks IOExceptions but not disastrous undefined behavior. Refcounting detects new garbage more quickly than periodic tracing, which is why it costs so much more in bus cycles. But both are dynamically detecting live objects and garbage. I've also seen systems where the only reference count values are "one" and "more than one", with the latter going uncollected until tracing.
    - erichocean 7y ago
      > it's just not common It's not common because it doesn't actually solve deterministic resource disposal, which is what is actually required, and a problem reference counting trivially solves.
    - cesarb 7y ago
      > Those resources tend to be too expensive to leave unused indefinitely The real issue is not that these resources are expensive. The real issue is that they're limited. The usual example is the file descriptor table: once all 1024 (or whatever your ulimit is) slots are in use, trying to open any new file or file-like resource will fail. The same can happen for instance with disk space (once I had a system which could only release a disk file when the corresponding in-memory object was closed, and someone else forgot to close the objects after using them, so all disk space allocated to that system was used up and it stopped working), database connections, and many others. In fact, the only reason this isn't an issue with memory (which is also limited) is that the garbage collector notices when it's getting full, and starts trying to collect garbage. It could in theory do so for other resources like file descriptors, but not all (how could it know that a remote database, shared with other users, is nearing its connection limit?), and it would probably be very inefficient (like having to do a full scan of the memory just to have a chance to find an open file handle which isn't referenced by any live object and therefore could be closed). The main advantage of reference counting is that it's deterministic: it doesn't just detect new garbage "more quickly", it detects new garbage immediately after it becomes garbage, which keeps the resource usage at a minimum.
p_l 7y ago
the latter is true, the former isn't - Ref counting is the first automatic memory management (actual name of the field) technique you learn in some of the seminal works. Then you learn why it sucks and not for taking space for counter.
afiori 7y ago
there was an article a few month ago here describing how refcounts and liveness reachability were the two dual basic GC and most simple GC are a combination of the two techniques.
- pron 7y ago
  Was it this one? https://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf https://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf Tracing and reference counting are two GC approaches that the paper shows are dual in some interesting ways and can have similar characteristic -- when both are sophisticated enough.
  - afiori 7y ago
    yes, thank you.
- erichocean 7y ago
  All programming languages are "duals" of each other in the Turing complete sense, though that doesn't tell you much beyond: they're programming languages. So here's how reference counting and garbage collection are duals: they both manage the memory lifetimes for objects not on the stack. If that blows your mind, you also might enjoy the above referenced paper and the meme that reference counting is "GC done badly".
  - afiori 7y ago
    I was referring specifically to the paper https://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf https://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf (found by pron in another comment). Where duality is in term of seeing reference counting as a form of negative-tracing. the paper also analyzes various techniques and claim that they mostly just mixes the two approaches. also if I can be facetious: > So here's how reference counting and garbage collection are duals: they both manage the memory lifetimes for objects not on the stack. that would be an equivalence, not a duality.
pjmlp 7y ago
What needs to die is for random devs, without compiler design background, assuming they know better than CS researchers, just to advocate reference counting.

earenndil 7y ago

Garbage collection means a way to automatically collect garbage. Reference counts automatically collect garbage. Therefore reference counting is a subset of garbage collection.

erichocean 7y ago
> Reference counts automatically collect garbage. Reference counts are used to manage resources, one of which is memory (and I'm assuming you are referring to no-longer-referenced memory as "garbage"). But that's not the only use for reference counts! You can, and should, use reference counts for external resources, such as files, or memory buffers on a GPU, or…. Garbage collection is COMPLETELY USELESS for managing non-memory resources because you need to be able to deterministically release non-memory resources (and oftentimes, memory resources—e.g., on the GPU). And since all a GC can do is examine memory, well, it doesn't work. Go ahead: point me to a 3D game engine using garbage collection for GPU resources. I'll wait. So yeah: "reference counting is a subset of garbage collection" is absolutely not true, and even the most basic knowledge of how reference counting is used in practice should be enough to convince anyone of that. Again: this meme needs to die. Garbage collection is not "super sophisticated reference counting", and in fact, can't even be used in most places where reference counting is used. It's not a substitution, or a superset, of reference counting. GC is a compelling alternative to reference counting for resources just in the main memory heap in some situations where performance (esp. total memory usage) isn't an important concern relative to, say, programmer productivity.
- erik_seaberg 7y ago
  You can close a non-memory resource when an object that owns it becomes garbage (Java calls this a "finalizer"), it's just not common. Those resources tend to be too expensive to leave unused indefinitely, and explicit closing risks IOExceptions but not disastrous undefined behavior. Refcounting detects new garbage more quickly than periodic tracing, which is why it costs so much more in bus cycles. But both are dynamically detecting live objects and garbage. I've also seen systems where the only reference count values are "one" and "more than one", with the latter going uncollected until tracing.
  - erichocean 7y ago
    > it's just not common It's not common because it doesn't actually solve deterministic resource disposal, which is what is actually required, and a problem reference counting trivially solves.
  - cesarb 7y ago
    > Those resources tend to be too expensive to leave unused indefinitely The real issue is not that these resources are expensive. The real issue is that they're limited. The usual example is the file descriptor table: once all 1024 (or whatever your ulimit is) slots are in use, trying to open any new file or file-like resource will fail. The same can happen for instance with disk space (once I had a system which could only release a disk file when the corresponding in-memory object was closed, and someone else forgot to close the objects after using them, so all disk space allocated to that system was used up and it stopped working), database connections, and many others. In fact, the only reason this isn't an issue with memory (which is also limited) is that the garbage collector notices when it's getting full, and starts trying to collect garbage. It could in theory do so for other resources like file descriptors, but not all (how could it know that a remote database, shared with other users, is nearing its connection limit?), and it would probably be very inefficient (like having to do a full scan of the memory just to have a chance to find an open file handle which isn't referenced by any live object and therefore could be closed). The main advantage of reference counting is that it's deterministic: it doesn't just detect new garbage "more quickly", it detects new garbage immediately after it becomes garbage, which keeps the resource usage at a minimum.

p_l 7y ago

the latter is true, the former isn't - Ref counting is the first automatic memory management (actual name of the field) technique you learn in some of the seminal works. Then you learn why it sucks and not for taking space for counter.

afiori 7y ago

there was an article a few month ago here describing how refcounts and liveness reachability were the two dual basic GC and most simple GC are a combination of the two techniques.

pron 7y ago
Was it this one? https://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf https://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf Tracing and reference counting are two GC approaches that the paper shows are dual in some interesting ways and can have similar characteristic -- when both are sophisticated enough.
- afiori 7y ago
  yes, thank you.
erichocean 7y ago
All programming languages are "duals" of each other in the Turing complete sense, though that doesn't tell you much beyond: they're programming languages. So here's how reference counting and garbage collection are duals: they both manage the memory lifetimes for objects not on the stack. If that blows your mind, you also might enjoy the above referenced paper and the meme that reference counting is "GC done badly".
- afiori 7y ago
  I was referring specifically to the paper https://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf https://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf (found by pron in another comment). Where duality is in term of seeing reference counting as a form of negative-tracing. the paper also analyzes various techniques and claim that they mostly just mixes the two approaches. also if I can be facetious: > So here's how reference counting and garbage collection are duals: they both manage the memory lifetimes for objects not on the stack. that would be an equivalence, not a duality.

pjmlp 7y ago

What needs to die is for random devs, without compiler design background, assuming they know better than CS researchers, just to advocate reference counting.