Earlier quoted context omitted.
>Computers are finite automata, they can't beget true randomness "Non-deterministic" in this context means that the behavior of the program is not deducible from the state of the current thread of execution, or more generally, from the state of the system being analyzed. If another thread modifies the current thread's memory, that modification is non-deterministic because you couldn't have foreseen it by following an…
> Reference counting is completely deterministic. If a thread holds the last reference to an object you can predict with certainty when that object will be released and which objects will also be released as a consequence, before actually releasing the object. You don't need to know what any other thread is doing to make this prediction. You're contradicting your own definition of determinism here. Other threads may…
Yes, other threads may be holding references to that object, except when the current thread holds the last one, which was the first thing I said in the statement you're responding to.
But that aside, you seem to be making the assumption that threads sharing state and object graphs between each other is a given, but that's completely false. Reference counting lets you design your application such that threads don't need to interact with each other to manage their memory. So you have the option of completely deterministic behavior, if your problem is amenable to such a solution. On the other hand, tracing GC doesn't have that option. Threads affecting each other is mandatory, even when no object is reachable from two threads simultaneously.
Between reference counting and tracing GC, only one permits deterministic object destruction.
>this is much easier said than done.
You're right, it's much better when your memory management system makes it completely impossible to debug stalls. Completely impossible is definitely better than difficult.