Re: Finalizers & Reference counting.
Nick Barnes <[email protected]>
| Newsgroups | gmane.comp.programming.garbage-collection.general |
|---|---|
| Message-ID | <[email protected]> |
At 2002-08-28 23:06:46+0000, "Boehm, Hans" writes: > > As a programmer I'm a big fan of the way GC makes my job a lot > > easier. However, the notion that GC has significant inherent > > performance problems bothers me. I'm curious whether anyone has > > any data and/or any experiments that might confirm or deny this > > claim. > So would I. But it's very hard to do. Yes. ISTR there was a quantity of research on this general subject about a decade ago, specifically relating to the ways in which copying GC can improve performance of memory hierarchies. Scott Nettles did a paper describing big improvements to the SML/NJ Appel collector (motivated by the thrashing sound filling his office), and there were a number of other papers including at least one PhD thesis with lots of graphs showing cache hits against time for different GC policies. Can't remember the author. It's pretty obvious that the ability to relocate objects so that live objects are adjacent (or even so that topologically close objects are close in the address space) is potentially good for the performance of the memory hierarchy. The basic argument says that without collection, fragmentation means that accesses are all over the map, but with collection, to-space fits into L2 (say). Then people largely lost interest in copying GC (because the focus of GC moved to C++, in which moving GC is impossible, and Java, in which it was very difficult). With non-moving GC, the arguments each way are harder (as Hans states). Torvalds is clearly prejudiced against garbage collection for other reasons (he calls it "lazy GC", which is the number one bogus reason given by old C hackers for disliking GC). I am therefore inclined to discount his opinions on its performance (although I don't have any numbers on the memory management of GCC). Nick Barnes