> The vast majority of resources are short-lived and don't create cycles. Our garbage collections "systems" should be designed for this case.

Many modern GC systems are tuned for exactly this. It often is called generational garbage collection and the youngest generation is tuned to quickly collect these short-lived and non cyclic objects.

I used to work in this field so I've got at least a decent grasp of what modern GC's do and don't do well:)

My point is that, what GCs do at runtime (discover garbage) can be done statically in all of these cases. The sole reasons GCs do that work at runtime is because of cycles.

Cycles aren't common at all and the answer shouldn't be "let's create a huge complex GC that handles all cases, then down the road we'll optimize for the common case" the answer should be "let's do the sane reasonable thing that handles the common case and push the problem of cycle-management to the programmer"

Someone mentioned returning a closure from a function. That's something that is done all the time in higher-level languages and hard to do without a GC.

Also, in general GC's are much faster than reference counting (especially when the reference count updates needs to be thread-safe), so the only reason one would use them is to have deterministic object destructions. These aren't common at all and should not be the deciding factor when choosing a memory management scheme.

RAII is great, and should be used where appropriate. I'm not sure what it has to do with reference counting, though. Reference counting is just a particularly slow and unreliable form of garbage collection; I don't see why you would ever prefer it to a proper garbage collector.

Tracing and Refcounting are each others duals,

www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf

Because it is deterministic? (i'm just guessing that what you call "proper" garbage collector is non-deterministic).

Furthermore, the only "advantage" I see in garbage collectors is that they can deal with cycles.

I say "advantage" because i'm of the strong opinion that having a cycle in your code is a software design error.

Say you are implementing a self-tracking objects model for data management. How do you fix the reversal of control required to manage that? Specifically you need to go from the representative object to the controller to store the fact that you changed.

Weak ptr/reference.

Also I would say that it's very uncommon to do/need something like this so it shouldn't be cited as an reason for cycles to be generally handled.

I have done weak pointer logic, it is not pretty.

Could you elaborate?

Entity Framework, when you modify an object it stores in a central location what the change was to be written out to a location latter.

It is performance wise infeasible to avoid that circular reference because it is very easy to pull back a lot of data from entity framework and change none of it.

Classic RAII in C++ is a limited form of ref-counting (only one ref).

I have to disagree with your second statement, ref-counting is extremely fast. If you consider it a GC then it's the fastest GC. It's also deterministic and does not pause.

> If you consider it a GC then it's the fastest GC. It's also deterministic and does not pause.

No, it's not, not unless you use a lot of cleverness. "We find that an existing modern implementation of reference counting has an average 30% overhead compared to tracing…" (They did perform a lot of optimizations to get it up to speed with tracing garbage collection... however, these are far beyond what shared_ptr does.)

http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2...

I'm a bit skeptical of the results of that paper without the seeing the source code and in what contexts they are performing the comparison. One can always find situations where one scheme is faster than the other but I'm not totally sure if micro benchmarks are representative of the real world. In long-lived servers, ref-counting can be preferable because it avoids random pauses. Maybe it's a latency vs throughput performance dichotomy. But yeah, thanks for posting that.

Reference counting doubles the number of memory access - you have to update the reference and the counter every time. That is a big performance hit. Reference counting may randomly halt your code, too, because you never know when you hit zero and the resource gets freed.

And you don't know how many resources will be freed when you drop the last pointer to that giant tree structure.

Of course, you could queue up and lazily delete the resources, but then you're back to nondeterministic behavior.

Two extra memory accesses plus whatever overhead for you have for locking if you are multi-threaded? That's pretty much the opposite of fast.

With refcounting you have:

  - Slow memory allocations (need to manage a fragmented heap)
  - Slow accesses and pointer handovers (updates to the refcounter)
  - Slow free (need to manage the free list)
  - No asynchronous pauses (since there is no garbage collector)

With a GC, you get:

  - Fast allocations (usually just an "add" instruction since the heap is not fragmented)
  - Zero cost accesses and pointer handovers
  - Zero cost free (just stop using the pointer)
  - Some asynchronous pauses and CPU usage while running the GC

It turns out that the cost of the first three points when using refcounting are much higher than that of the GC. Another reply to your post included references to actual research on this subject.

I think in multi-threaded code ref-counting usually uses atomic_fetch_add instructions. This results in a memory barrier and is much more expensive that you might think.