4 ms·

>GC pauses have been one of the major barriers to using garbage collected (read: higher-level) languages There is such a thing as reference counting :)

DaiPlusPlus 8y ago
Trivial reference-counting can lead to memory leaks when you have an object graph that’s disjoint from an RC root object. Non-trivial reference counting starts to look like mark-and-sweep GC. And even then, when a ref count drops to zero, the runtime cost of destruction and deallocation of particular objects can be expensive. Stop-the-world GC is bad, but “make a blocking call because you can’t use async APIs in destructors” is worse - especially when the destructor runs in a program thread instead of a GC thread. I feel that languages which provide support for defined object ownership and lifetime (Rust, any others?) will become the future because in many scenarios object-lifetime can be nailed-down by the compiler and thus eliminate the need for GC or ARC.
- antpls 8y ago
  From my understanding of Rust, you will still pay the runtime cost of destruction and deallocation of objects with the object lifetime system ? It's like reference counting, but precomputed by the compiler. Please correct me if I'm wrong.
  - DaiPlusPlus 8y ago
    Right. It’s just easier to reason about the process with Rust’s ownership system compared to a reference-counting or GC system.
  - unrealhoang 8y ago
    It’s like manual allocate/deallocate. Only that the compiler will insert free (or drop, in case of Rust) for your variables when it reaches end of scope.
  - steveklabnik 8y ago
    The way the "it's like reference counting" mental model goes wrong is that things don't live arbitrarily wrong. Reference counting is used to extend the life of things, Rust will not do that. But yes, it's malloc and free.
pron 8y ago
What makes you think reference counting leads to shorter pauses than tracing? While it is absolutely true that sophisticated implementations of garbage collection via ref counting can exhibit similar performance to sophisticated tracing algorithms[1], most implementations of ref counting aren't nearly as sophisticated as modern implementations of tracing, and tend to be worse. [1]: https://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf https://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf
- tambourine_man 8y ago
  Not necessarily shorter, but predictable pauses.
  - pjmlp 8y ago
    Very predicatable indeed. Go and C# running circles around Swift. "35C3 - Safe and Secure Drivers in High-Level Languages" https://www.youtube.com/watch?v=aSuRyLBrXgI https://www.youtube.com/watch?v=aSuRyLBrXgI Possible stack overflows and unexpected pauses due to heavily nested data structures. "CppCon 2016: Herb Sutter “Leak-Freedom in C++... By Default." https://www.youtube.com/watch?v=JfmTagWcqoE https://www.youtube.com/watch?v=JfmTagWcqoE
  - pron 8y ago
    If your memory usage is regular and predictable, then both ref counting and tracing would behave regularly and predictably, and if it isn't, neither is.

DaiPlusPlus 8y ago

Trivial reference-counting can lead to memory leaks when you have an object graph that’s disjoint from an RC root object. Non-trivial reference counting starts to look like mark-and-sweep GC. And even then, when a ref count drops to zero, the runtime cost of destruction and deallocation of particular objects can be expensive. Stop-the-world GC is bad, but “make a blocking call because you can’t use async APIs in destructors” is worse - especially when the destructor runs in a program thread instead of a GC thread. I feel that languages which provide support for defined object ownership and lifetime (Rust, any others?) will become the future because in many scenarios object-lifetime can be nailed-down by the compiler and thus eliminate the need for GC or ARC.

antpls 8y ago
From my understanding of Rust, you will still pay the runtime cost of destruction and deallocation of objects with the object lifetime system ? It's like reference counting, but precomputed by the compiler. Please correct me if I'm wrong.
- DaiPlusPlus 8y ago
  Right. It’s just easier to reason about the process with Rust’s ownership system compared to a reference-counting or GC system.
- unrealhoang 8y ago
  It’s like manual allocate/deallocate. Only that the compiler will insert free (or drop, in case of Rust) for your variables when it reaches end of scope.
- steveklabnik 8y ago
  The way the "it's like reference counting" mental model goes wrong is that things don't live arbitrarily wrong. Reference counting is used to extend the life of things, Rust will not do that. But yes, it's malloc and free.

pron 8y ago

What makes you think reference counting leads to shorter pauses than tracing? While it is absolutely true that sophisticated implementations of garbage collection via ref counting can exhibit similar performance to sophisticated tracing algorithms[1], most implementations of ref counting aren't nearly as sophisticated as modern implementations of tracing, and tend to be worse. [1]: https://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf https://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf

tambourine_man 8y ago
Not necessarily shorter, but predictable pauses.
- pjmlp 8y ago
  Very predicatable indeed. Go and C# running circles around Swift. "35C3 - Safe and Secure Drivers in High-Level Languages" https://www.youtube.com/watch?v=aSuRyLBrXgI https://www.youtube.com/watch?v=aSuRyLBrXgI Possible stack overflows and unexpected pauses due to heavily nested data structures. "CppCon 2016: Herb Sutter “Leak-Freedom in C++... By Default." https://www.youtube.com/watch?v=JfmTagWcqoE https://www.youtube.com/watch?v=JfmTagWcqoE
- pron 8y ago
  If your memory usage is regular and predictable, then both ref counting and tracing would behave regularly and predictably, and if it isn't, neither is.