Of course you can know that, because you know the type of every object. If you're deallocating a big data structure, then the impact will be big. Its easy to choose not to deallocate such objects at an inconvinient time by holding references to them. Compare this with GC where the collection can occur at any time after deallocation, e.g. during an animation.
It is also possible to know, approximately, when a GC collection will take place, this is what GC profilers are for.
The thing is that most discussions tend to be reduced to RC vs GC, as if all GCs or RCs where alike, whereas the reality is more complex than that.
RC, usually boils down to dumb RC, deferred RC or RC with couting elision via the compiler. Additionally it can have weak references or rely on a cycle collector.
Whereas GC, can be simple mark-and-sweep, conservative, incremental, generational, concurrent, parallel, real time, with phantom and weak references, constrainted pause times, coloured....
As for frame drops during animations, I think pauses in a missile control system is not something one wishes for:
Sure, but then real-time systems are a very special use case with their own languages, tools and techniques. Real time GCs are severely limited and would not be suitable for use in a general purpose context.
You can do almost the same with a garbage collector - keep references alive until a convenient point is reached, than kill those last references and manually force a collection. Not that it seems a good idea, but if you need a level of control as described by you, then you are already actively fighting against automatic reference counting and there seems no point to use any kind of automatic resource management in the first place, at least for the relevant objects.
It's not possible to do that in Java, though it would work in C#. Retaining references really is not "fighting against automatic reference counting", it's the opposite: the reference clearly and unambiguously defines the lifetime of the object, including deallocation. This is by design and ARC can still be used for any shared references to the object. Forcing GC on the other hand, would be fighting against it because you're circumventing its usual operation.
I think technically you could achieve this by having multiple heaps, kind of like custom allocators in other languages.
If Java had a placement syntax like
new (HeapReference) SomeClass(); => allocate in custom Heap
Then you could just turn off GC for that heap, and then blow the whole thing away when it got full. Or, you could have a more fine grained API to allow GC on these custom heaps. Perhaps you could even allow copying objects back to the main heap. You'd have to ban cross heap references or have a smart API that lets users pin an object in the main heap while it is known to be referenced by an object in custom heap.
Most of the time in client applications, you only care about GC pauses on the main UI rendering thread, but GC pauses in other threads are less obvious because there's no jank, just that latency may go up for some operations.
You could have a kind of best of both worlds with languages that support non-GC allocation for your UI thread, but GC everywhere else.
It wouldn't work reliably in C# either. Both platforms allow you to inform the GC that now would be a good time to collect, but in both systems the GC can ignore your advice. C# has structs which will try to allocate on the stack, but that is potentially a big (or impossible) refactoring on your program (unless you plan ahead).
A GC cannot occur at any tie after deallocation. Well, I guess it depends on the collector really, but usually it happens on allocation. If you avoid allocations, you also avoid collections.
