[pizlonator]

They are not interchangeable. The semantics are observably different. Therefore, RC is not GC.

Reference counting gives you eager destruction. GC cannot.

GC gives lets you have garbage cycles. RC does not.

I think a part of the GC crew reclassified RC as GC to try to gain relevance with industry types during a time when GC was not used in serious software but RC was.

But this is brain damage. You can’t take a RC C++ codebase and replace the RC with GC and expect stuff to work. You can’t take a GC’d language impl and replace the GC with RC and expect it to work. Best you could do is use RC in addition to GC so you still keep the GC semantics.

[cryptonector]

> GC gives lets you have garbage cycles. RC does not.

This is the biggest difference, but if you disallow cycles then they come close. For example, the jq programming language disallows cycles, therefore you could implement it with RC or GC and there would be no observable difference except "eager destruction", but since you could schedule destruction to avoid long pauses when destroying large object piles, even that need not be a difference. But of course this is a trick: disallowing cycles is not a generic solution.

[gf000]

> Reference counting gives you eager destruction. GC cannot.

Tracing GC can't. Reference counting, which is by definition a GC can. It's like insects vs bugs.

And destructors are a specific language feature. No one says that they are a must have and if you don't have them then you can replace an RC with a tracing GC. Not that it matters, a ladybug is not the same as an ant, but they are both insects.

[pizlonator]

The best part of these conversations is that if I say “garbage collection”, you have zero doubt that I am in fact referring to what you call “tracing garbage collection”.

You are defining reference counting as being a kind of garbage collection, but you can’t point to why you are doing it.

I can point to why that definition is misleading.

Reference counting as most of the industry understands it is based on destructors. The semantics are:

- References hold a +1 on the object they point to.

- Objects that reach 0 are destructed.

- Destruction deletes the references, which then causes them to deref the pointed at object.

This is a deterministic semantics and folks who use RC rely on it.

This is nothing like garbage collection, which just gives you an allocation function and promises you that you don’t have to worry about freeing.

[gf000]

> https://web.eecs.umich.edu/~weimerw/2008-415/reading/bacon-g...

They are different approaches for the same thing: automatic memory management. (Which is itself a not trivial to define concept)

One tracks liveness, while the other tracks "deadness", but as you can surely imagine on a graph of black and white nodes, collecting the whites and removing all the others vs one by one removing the black ones are quite similar approaches, aren't they?

[pizlonator]

You’re not going to convince me by citing that paper, as it’s controversial in GC circles. It’s more of a spicy opinion piece than a true story.

I agree that RC and GC are both kinds of automatic memory management.

RC’s semantics aren’t about tracking deadness. That’s the disconnect. In practice, when someone says, “I’m using RC”, they mean that they have destructors invoked on count reaching zero, which then may or may not cause other counts to reach zero. If you squint, this does look like a trace - but by that logic everyone writing recursive traversals of data structures is writing a garbage collector

[pjmlp]

A RC algorithm implementation using a cycle collector, or deferred deletion on a background thread, to reduce stop the world cascade deletion impact, is....

[pjmlp]

Regarding being "deterministic",

CppCon 2016: Herb Sutter “Leak-Freedom in C++... By Default.”

https://www.youtube.com/watch?v=JfmTagWcqoE