Two things. First, most GC doesn't actually deallocate anything, but that's a minor nitpick. The second, more important note, is that you are now describing a s

Two things. First, most GC doesn't actually deallocate anything, but that's a minor nitpick. The second, more important note, is that you are now describing a system where everything is garbage collected. This needn't be the case. In a language like Go, you have control over what get's stack allocated and what is placed in a GC. When that choice can be made, then you really can tell when given objects are deallocated. Of course, since the stack is a fixed size construct, I guess you don't really deallocate these things either... It's also worth noting that GCs rarely does anything because it feels like it, but because you are allocating past a certain limit. Knowing the size of objects, and given that the allocator can provide you with the current size of allocated objects, you should be able to determine if a GC is likely to incur in the next lines of code. This determination becomes harder when threads enter the picture, unless you're using a GC scheme like Erlang, which have one GC per process (lightweight thread). Some GCs also allow you to pause and resume them, for when you really want to avoid GC cycles, this can of course lead your program to crash if you allocate past your limit. As always in computer science, 'it depends'.