Hacker News Reader

Comment by yencabulator | Hacker News Reader

> it has more predictable runtime performance

Not that much more. Drop the last reference to e.g. a tree and you're doing an arbitrary amount of work to free it, right there. People resort to hacks like sending messages to "freeing threads" dedicated to that.

View on HN

the work is predictable and the amount not arbitrary

By that standard, all gc work is predictable and the amount not arbitrary.

no, it is not. A gc won't run at the end of the scope when the reference is droped. And if it runs, the amount of work is unknown.

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

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

Reply on news.ycombinator.com