Either the size of the data structures created is limited and known, or it isn't. Whether the work is done in a refcount-decrementing recursive descent or a tracing garbage collector doesn't change that part.

a GC still won't run at the end of the scope - it will run at an unknown time and do an unknown* amount of work at the times it is running.

* subset of all allocations until it runs

And a refcounted tree freeing won't necessarily run at the end of the current scope, that depends on what other work is being done currently, and the size of the tree is a subset of all allocations until last user drops it.

and yet whether or not other work is being done currently is in your control, thus predictable (unless you chose to give control out of your hands e.g. by introducing two threads racing against each other); same regarding the subset

It is also unknown how much work will be performed if ARC goes out of scope.

if the arc is the last: the data structure is destructed and deallocated + atomic check

if the arch is not the last: atomic check

You might lose 100 ns or 300 ms. When? Nobody knows. You lose nothing when going out of scope with GC.

as a programmer you know and you can even control it by designing the appropriate scope and moving between scopes

> You lose nothing when going out of scope with GC.

actually, you don't know

Yes, I can, e.g. by implementing deferred deallocation, which is a primitive GC form.

> actually, you don't know

I know because I’ve verified it.

> Yes, I can, e.g. by implementing deferred deallocation, which is a primitive GC form.

sounds more like a form of manual memory management

Manual management involves an explicit function call. Functions called by a destructor are considered automatic.

How does this relate?

What exactly don't you understand?

how this relates to garbage collectors

Because that is precisely the trade-off we're discussing.

With immediate reference-counted reclamation, dropping the last reference can put an arbitrarily large amount of destruction and deallocation work on the current thread. If you defer that reclamation to get it off the critical path, you have introduced a collector that reclaims unreachable objects later.

Whether that collector discovers garbage by tracing or receives zero-reference objects from reference counting is an implementation detail. In both cases, memory reclamation is automatic and deferred.

So the supposed distinction "with ARC I know when I pay the reclamation cost, with GC I don't" only holds if you're willing to pay an unbounded reclamation cost synchronously when the last reference is dropped.

> Whether that collector discovers garbage by tracing or receives zero-reference objects from reference counting is an implementation detail

No, it is not. The latter is deterministic, predictable and controllable.

> only holds if you're willing to pay an unbounded reclamation cost synchronously when the last reference is dropped.

No, just because moving an arc/deallocation between threads doesn't change anything about the deallocation.

Aside that, contrary to GCs it's not unbounded,but bounded by the deallocation cost of the given arc.