Re: why malloc/free instead of GC?

I would add:

GC object roundtrip times are pretty much unavoidably proportional to the object size, where malloc + free times can be nearly constant.  If you allocate primarily large objects, malloc+free will be cheaper.  (For sufficiently small objects, it usually isn't, at least based on my measurements.  Conservative collectors like large objects even less.)

On the other hand:

I think finalization isn't an argument against tracing GCs.  You run into fundamentally the same issues with, say, user-implemented reference counting in C++.  The problems are inherent in abstracting away or hiding precise deallocation times.  And the problems aren't anywhere near unsolvable. See my 2003 POPL paper (also at http://www.hpl.hp.com/techreports/2002/HPL-2002-335.html) for details.

Finalization also usually provides an easy mechanism for dealing with libraries requiring explicit deallocation calls.  Thus I don't think that's a major problem.

Hans