[gclist] Finalizers & Reference counting.

[Nick Barnes]

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