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?

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. Reference counting might feel more incremental than GC, but really is not. There are tricks you can use, but you're better off with a fast, modern, pauseless real GC that comes with tons of other benefits. Look: modern GCs simply don't have pause time issues. The problem has been solved. We have concurrent marking and concurrent sweeping. Stop living in the 1990s!

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 ago
  Reference 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".
scotty79 5y ago
I wonder if you could just pass this 10000 tree node root to another thread that will just drop it. This should result in no pause for main thread. Apparently you need Arc for that not Rc which shouldn't have much overhead over Rc in reasonable scenarios.
- mplanchard 5y ago
  Yes, doing big drops in a subthread is a good way of avoiding pauses when dropping large objects of any kind.
  - native_samples 5y ago
    Which is, of course, largely what concurrent GC is about.
- pjmlp 5y ago
  Yes, that is how C++/WinRT handles cascading deletion of COM instances, however when you are going down that route, it is basically a poor man's tracing GC.
  - scotty79 5y ago
    However it just for the stuff you need it for. It's not all encompassing. It's not mandatory part of the language.
    - pjmlp 5y ago
      True, and unfortunately a reason why we keep having CVEs related to memory corruption.
- edude03 5y ago
  There is a thread I came across on hacker news that does exactly that https://news.ycombinator.com/item?id=23362518 https://news.ycombinator.com/item?id=23362518 - this question reminded me of it

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 ago
Reference 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".

scotty79 5y ago

I wonder if you could just pass this 10000 tree node root to another thread that will just drop it. This should result in no pause for main thread. Apparently you need Arc for that not Rc which shouldn't have much overhead over Rc in reasonable scenarios.

mplanchard 5y ago
Yes, doing big drops in a subthread is a good way of avoiding pauses when dropping large objects of any kind.
- native_samples 5y ago
  Which is, of course, largely what concurrent GC is about.
pjmlp 5y ago
Yes, that is how C++/WinRT handles cascading deletion of COM instances, however when you are going down that route, it is basically a poor man's tracing GC.
- scotty79 5y ago
  However it just for the stuff you need it for. It's not all encompassing. It's not mandatory part of the language.
  - pjmlp 5y ago
    True, and unfortunately a reason why we keep having CVEs related to memory corruption.
edude03 5y ago
There is a thread I came across on hacker news that does exactly that https://news.ycombinator.com/item?id=23362518 https://news.ycombinator.com/item?id=23362518 - this question reminded me of it