In the world I live in, I usually hear the phrase "automatic versus manual memory management" for the "high-level languages versus C" thing, and "garbage collection" for scanning for unreferenced data periodically (LISP style).
In my humble opinion it is a bit cleaner to not call the automatic memory management "GC", because e.g. with refcounting there is no "garbage" which could be later "collected".
Posted Nov 20, 2011 0:04 UTC (Sun) by elanthis (guest, #6227)
[Link]
Yeah, it's all just terminology.
Since I'm a nerd and have to be pedantic about such things though (I'm easy to need-snipe), "garbage" is still a correct term in reference counting schemes. That the garbage object is almost immediately collected rather than sitting around a while until collection isn't really relevant; it's still for a brief moment a valid memory-consuming object that is known to be unneeded (ref count hit zero) but not yet reclaimed. :)
In fact, even in many ref counting systems, reclaiming is not instantaneous, but rather delayed. Objects with a ref count of zero are just put into a list of dead objects, and that list is "cleaned" at the end of the app's main loop. This is handy when you realize that an object might become dead during a callback from one of the object's methods, for instance, or when you allow "temporary" raw pointers (nothing persisting past a function call's lifetime) to avoid excessive ref count increments/decrements in tight inner loops or in cache-friendly code.
In object pool setups, the object might not even be "reclaimed" until another object is created (replacing the dead object in memory).
Not tricks you find in general purpose setups, but definitely common in things like games (which is one of the reasons why C++ is still king of the hill in that domain, and only little casual games are ever implemented in high level languages with a one-size-better-fit-all-or-you're-screwed approach to object management and low-level data structures.)