[AnimalMuppet]

Well, GC has indeterminate timing in and of itself. Reference counting does not. It can still trigger indeterminate timing if the destructor calls free, or if the "thing" going out of scope is a pointer, but that's on the destructor or the pointer, not on reference counting per se.

[Someone]

> but that's on the destructor or the pointer, not on reference counting per se.

It is on reference counting per se. If the reference count of a reference goes to zero, the runtime has to make the memory available for reuse. That’s what I called ‘calling free’.

Also, about “GC has indeterminate timing in and of itself”. Again: define what you mean by it. Yes, The timing of allocating an object can vary depending on the state of your memory allocator, but that’s the same with reference counting.

(even allocating an object on the stack and then writing to it can have variable timing on many OSes. If you look really close, even decreasing a stack pointer can have variable timing on modern pipelined CPUs due to data dependencies)

And as I said, the GC work to find and reclaim unreachable objects can run on separate thread(s).

[AnimalMuppet]

I think I understand you now. You don't do reference counting for something "on the stack" (in C++ terms), you only do it for something on the heap. Things on the stack can have destructors, but that gets called when the stack frame goes out of scope. So anything reference counted, when the count goes to zero, will not only have its destructor run, but will also be deallocated on the heap (calling free).

And then whether you blame that on reference counting or garbage collection or heap allocation is kind of an arbitrary distinction.

OK, I get it. You were right :-)