Re: why malloc/free instead of GC?

You might want to refer to some of the recent discussions on the GCC
(GNU compiler collection) mailing list.  One hotly discussed topic is
the changes in the memory access patterns and other subtle hidden costs.

Memory access pattern costs are difficult to measure.  Some applications
greatly benefit from reusing freed memory quickly because of CPU cache
issues; GC may work against that.  Yet many allocation patterns are well
suited to GC.  Some apps are very sensitive to clustering of the objects
due to the access patterns, and depending on how you allocate objects
you can do well or horribly.  Depending on your memory allocator logic
it may have little or lot to do with GC costs.

On the other hand, memory allocation assumptions build into designs
which makes it hard to compare a system with and without GC.  For an
unbiased comparison you might have to rewrite the whole system.

BTW, GCC doesn't use the BDW collector but its own scheme, which is
another factor to fold into the impact calculations.

//lat
-- 
prototype, n.:
  First stage in the life cycle of a computer product, followed
  by pre-alpha, alpha, beta, release version, corrected release
  version, upgrade, corrected upgrade, etc.  Unlike its
  successors, the prototype is not expected to work.