Hacker News Reader

Comment by quotemstr | Hacker News Reader

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!

View on HN

> 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.

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

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.

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.

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.

However it just for the stuff you need it for. It's not all encompassing. It's not mandatory part of the language.

True, and unfortunately a reason why we keep having CVEs related to memory corruption.

There is a thread I came across on hacker news that does exactly that https://news.ycombinator.com/item?id=23362518 - this question reminded me of it

Yes, doing big drops in a subthread is a good way of avoiding pauses when dropping large objects of any kind.

Which is, of course, largely what concurrent GC is about.

Reply on news.ycombinator.com