>>17It has one of the best in the industry [i]according to benchmarks[/i]. See the rant above about infrequent collections. It has low overhead when all is said and done, as long as you don't start paging. There's also the fact that it allocates nearly everything.
The truth about good GC is it really depends on your application and environment. If you have infinite memory, let the OS collect for you on exit. If you can dedicate decandant amounts of memory to a single app, Java will be fast as long as you can tolerate the pauses.
Perl uses refcounts which is not GC to GC people but it's GC to everyone else. Pauses are rarely noticeable, and clean code rarely causes problems for the cycle collector.
The naive copying collector described in the SICP lectures is not at all bad for worst-case. It's very nearly linear time, and reduces fragmentation to zero. Run this often and you will have much less wasted memory than Java.
I don't know anything notable about the JavaScript GCs but Epic Citadel runs a lot better than Minecraft on my system, so I think the EichMonkey GC is probably pretty good when the allocation/deallocation patterns are clean. It makes sense, because Mozilla was obsessed with memory footprint, and collecting as early as possible is the best thing you can do for that with regards to the GC. They also went shopping around for allocators that combat fragmentation, which is a good combo.
You might have heard of Hans Boehm:
Copying collectors can also offer better worst-case space bounds than nonmoving collectors, particularly if real-time constraints are present. Thus they may be appropriate for certain embedded real-time applications.
However, he also says:
There is growing evidence that copying collectors are a poor choice for old objects in a typical desktop application. They often result in unnecessarily large memory footprints, and paging where none is really necessary. The net effect can be disastrous performance.
http://www.hboehm.info/gc/complexity.html (1995)
In the end, GC is not for everything, but it's fine for most games if you have a little headroom for a well-placed GC. Enforced GC is not so great for most AAA 3D titles, but that doesn't stop people from making Android ports of FPS games. If you can choose your GC (and what is subject to collection), things look very nice indeed. You can just put roots of data known to be transient in an arena (reasonably easy to do in C++ and friends) and collect on the arena. The cost is roughly: up to 2x memory overhead (for arena only), 2x the cost of pointer derefs (for arena only) and a collection in linear time on the number of objects allocated to the arena, run perhaps every frame.
So yeah, for heavy-lifting non-optional non-pluggable GC basically ruins your day. The more choices you have in GC the better, but you are replacing the effort of manual memory management with the need for somewhat specialist knowledge needed in choosing the strategy.
I like GC in scripting languages and in functional and math-oriented languages. Whatever naive GC is there usually suffices (some are awful though), and if it doesn't the languag is still suitable for prototyping most things.