3 ms·
> Naive synchronous reference counting can lead to large pauses as well. What happens when you drop the last reference to the root of a 10,000-node search tree?
by cesarb 5y ago
> Naive synchronous reference counting can lead to large pauses as well. What happens when you drop the last reference to the root of a 10,000-node search tree?
> You do 10,000 reference deferments and free()s.
You do all that work at the precise point where the last reference was dropped.
What people who complain about GC pauses dislike is the GC causing pauses in completely unrelated threads, including these threads that aren't even allocating or deallocating anything at that moment.
- deschutes 5y agoReference counting implies non deterministic frees. If you knew who the final owner of an object was, you wouldn't need reference counting. While it is true that many (most?) GCs have STW sections, it's not at all clear that it is a bad tradeoff.
- klabb3 5y ago> You do all that work at the precise point where the last reference was dropped. True, but rarely meaningful in practice. People don't anticipate spikes at implicit deallocation sites. On the contrary, they typically use RCs to share data without worrying about exact destructure time (i.e. same reason as GC), and thus will be caught off guard in either case. In fact so much so that even experts frequently introduce accidental RC cycles (causing hard-to-debug leaks). In the cases where you actually want destruction to be deterministic (e.g. large allocations, graceful teardown, kernel resources etc), neither a traditional GC nor RCs are a good solution. The simplicity and elegance of Rusts RAII scoped ownership model largely goes away with async, due to the unavoidable "Arc-hell".