8 ms·

Yes, slower than modern GC, but predictable and deterministic. Note that the parent comment never claimed it was faster, just that it avoids 'stop the world' wh

Yes, slower than modern GC, but predictable and deterministic. Note that the parent comment never claimed it was faster, just that it avoids 'stop the world' which can be a problem in realtime contexts (e.g. games, audio).

jmgao 9y ago
Reference counting isn't inherently more predictable than tracing garbage collection. Take the example where your thread is the last one to deref a gigantic object graph. You're stuck holding the bag on traversing the entire graph and destructing it all at once, when a tracing gc could do it piecemeal (and on a dedicated background thread, instead of on your real worker threads).
- derefr 9y ago
  If objects that hit zero refs have their reference pushed into the queue of a dedicated GC thread, is that not still called RC, or is that called something else?
  - papaf 9y ago
    Researchers tend to call them Reference Counted Garbage Collectors. Here is a random example that actually recommends the opposite (RC in old generations, mark and sweep in the young generation): https://link.springer.com/chapter/10.1007/3-540-36579-6_14 https://link.springer.com/chapter/10.1007/3-540-36579-6_14
BlackFingolfin 9y ago
Reference counting can also lead to big cascades of objects being freed, which can make it impractical in realtime context as well. This makes RC useless for systems which have hard constraints here (e.g. automotive). And of course, once you are multi-threaded, you can more or less forget about "predictable and deterministic" with RC, too. In contrast, there are real time capable garbage collectors.
- SolarNet 9y ago
  Ehhh, except that rust's borrowing system is a really great aid to prevent those sorts of things. And, one can easily make a thread responsible for deallocating the cascading objects. The point being that reference counting allows one more control over how deallocation is done. Besides, the real time capable garbage collectors are basically just backed in implementations of exactly that. With reference counting, it can be written in the language itself, rather than as a tunable external part of the implementation, which is useful.

jmgao 9y ago

Reference counting isn't inherently more predictable than tracing garbage collection. Take the example where your thread is the last one to deref a gigantic object graph. You're stuck holding the bag on traversing the entire graph and destructing it all at once, when a tracing gc could do it piecemeal (and on a dedicated background thread, instead of on your real worker threads).

derefr 9y ago
If objects that hit zero refs have their reference pushed into the queue of a dedicated GC thread, is that not still called RC, or is that called something else?
- papaf 9y ago
  Researchers tend to call them Reference Counted Garbage Collectors. Here is a random example that actually recommends the opposite (RC in old generations, mark and sweep in the young generation): https://link.springer.com/chapter/10.1007/3-540-36579-6_14 https://link.springer.com/chapter/10.1007/3-540-36579-6_14

BlackFingolfin 9y ago

Reference counting can also lead to big cascades of objects being freed, which can make it impractical in realtime context as well. This makes RC useless for systems which have hard constraints here (e.g. automotive). And of course, once you are multi-threaded, you can more or less forget about "predictable and deterministic" with RC, too. In contrast, there are real time capable garbage collectors.

SolarNet 9y ago
Ehhh, except that rust's borrowing system is a really great aid to prevent those sorts of things. And, one can easily make a thread responsible for deallocating the cascading objects. The point being that reference counting allows one more control over how deallocation is done. Besides, the real time capable garbage collectors are basically just backed in implementations of exactly that. With reference counting, it can be written in the language itself, rather than as a tunable external part of the implementation, which is useful.