[mypalmike]

But what if my application is say, a diagramming GUI where the user can create many nested items. When they delete a million items by removing a top level item, how are you going to avoid a pause if using single threaded synchronous RC? Per object determinism doesn't mean systemic determinism on a dynamic graph.

[int_19h]

You're not going to avoid it. But you will know that it'll happen at that exact moment.

Whether that is actually important or not depends on the use case. Personally, I think that GC is plenty good enough for most GUI apps other than games, and allows for non-contorted modelling of said GUI (e.g. with backreferences where they make sense).

[mypalmike]

You say, "you will know that it'll happen at that exact moment". I'm curious what you mean by this.

Do you mean that the user will know? Well sure, that's the pain point to avoid in this case. Anyone who has tried to quit certain versions of various browsers after a long session with many tabs, etc. will know this pain when closing a window. Server side applications can have similar issues.

Or do you mean the code will "know"? That is, the code will need to predict, at runtime, that a code path will be expensive and choose a memory release strategy based on some criteria?

Or do you mean the designer of the code will know, and avoid RC before implementing?

Honest question, I'd like to understand your perspective. Thanks.

[int_19h]

This was specifically a response to:

> you know when deallocations happen in any codebase full of conditionals depending on outside effects

What I'm saying is that the author of the code, and anyone else who can read and understand it, will know that, if the user does X, Y, and Z, it'll trigger a deeply nested release of an object graph that'll cause a period of non-responsiveness visible to the user.

Whether the author will consider this acceptable or not is a different question.