I never really understood why you would actually need a garbage collector or do memory management. I suppose I might be misguided, but couldn't one just garbage collect everything at the end of the current block, i.e when the object occupying the memory goes out of scope.
You can do that for some variables, but not all of them. The trick is knowing when you can do that. Some references may be shared with other sections of code. If those references get deleted then the second section of code that still contains a reference to the deleted objects won't have access to them anymore. You can use escape analysis to determine ahead of time which objects are safe to delete and which ones are not. Those that don't escape can be stored on the stack (or a stack, but normally it's combined with the call stack used to determine where functions resume after return statements). When the call stack unwinds, the stack space allocated for those objects can be freed at the same time. For objects that may need to stick around longer than the function scope, then those are allocated on the heap (shared memory space.)
[size=smaller]It's slightly off topic, but - just in case you're asking because you read something from a C++ website - sometimes garbage collectors have a time advantage over scope triggered destructor memory management patterns and almost always have an advantage over reference counting. The overhead of memory management may be large enough for single objects that it's slower to delete only one at a time. You can budget time to delete and dispose objects in batches and actually use less time overall. It's also misunderstood that reference counting and scope based destructor behavior provides better real time characteristics. Some programs could create chain reactions that could stall the program longer than a real time garbage collector would.[/size]
Escape analysis is very fast, operating in linear time I'm told; and can be run on ever expanding scopes depending on how far you want to take it. In theory you could end up with the entire heap allocated on the stack if your code fits well enough.
What do you mean by linear time? Can't you do good escape analysis at compile time? Stack allocation takes constant time. And unless you're interpreting code on the fly, then I can't imagine what time efficiency you're referring to. The analysis is probably fast and only needs to be done once.
