| |||||||||||||
GC in common languagesGC in common languagesPosted Nov 19, 2011 11:20 UTC (Sat) by Yenya (subscriber, #52846)In reply to: This is partially true... by Cyberax Parent article: Interview with Andrew Tanenbaum (LinuxFr.org)
: > Ada may not be big on desktop today, yet it still used quite
: > heavility where security is important. But guess what: no GC. : > In most impementations, at least.
> But then there's .NET and Java, Python and Perl, Erlang and Haskell
Just for the sake of correctness, Perl does not use GC at all - Perl uses reference counting, and as soon as the count drops to zero, the object's memory can be recycled (after a destructor finishes). This is much more simple than GC, destructors are called in a deterministic place of the program, but it also has drawbacks, such as not being able to free a circular reference, which is not referenced from the outside world (see Scalar::Util::weaken for the solution).
-Yenya
(Log in to post comments)
GC in common languages Posted Nov 19, 2011 20:45 UTC (Sat) by elanthis (guest, #6227) [Link]
Reference counting is a form of automatic garbage collection, and not even the most efficient one at that. "GC" is not limited solely to mark-and-sweep and it's offspring.
GC in common languages Posted Nov 19, 2011 20:57 UTC (Sat) by Yenya (subscriber, #52846) [Link]
OK, sorry for the confusion then.
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".
GC in common languages 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.)
|
|||||||||||||