3 ms·
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
by 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 agoFrom 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 agoRight. It’s just easier to reason about the process with Rust’s ownership system compared to a reference-counting or GC system.
- unrealhoang 8y agoIt’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 agoThe 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.