[gclist] Finalizers & Reference counting.

[Boehm, Hans]

As has been pointed out, this thread actually seems to be confusing liberal allocation and pointer-chasing with GC algorithm issues.  I think the former clearly hurts performance and should be avoided when possible.  But it clearly isn't always possible to avoid, and gcc3 is significantly different from gcc2.95 in many ways.  My understanding is that the collector was added in the first place because the front-ends, particularly the one for C++, became unmaintainable without it.

On the algorithm side, we also have to keep in mind both that the gcc collector is a fairly specialized beast (AFAIK, it collects only the front-end tree data structure and has nothing to do with the back-end, it uses explicit root registration, and it's single-threaded.)  Based on a quick look at the code (and assuming that ggc-page.c is the collector that usually gets used), it seems to generally do the right things, but it hasn't been heavily tuned.  In particular:

- It seems to consistently use power-of-2 object sizes for reasons that aren't completely clear to me.  This sounds expensive, unless tree nodes are carefully tuned to fit well into these sizes.  (I don't know if they are.  I suspect there are people lurking on this list who do.)

- The implementation favors clean structure over speed.  I think it takes something like 3 or 4 function calls to mark an object.  The marker is recursive.  It doesn't attempt to prefetch, although there are places at which it would almost certainly be substantially profitable (if you could deal with the X86 prefetch instruction mess).

Hans