[gclist] Precise GC's performance

[Nick Barnes]

> Actually, I believe Charles' answer is very relevant to your question.
> One of the main differences between conservative and precise collection is
> that precise GC can use copying collection. Copying collectors have a much
> faster malloc than mark-sweep collectors. If collections rarely take place
> (i.e. huge space overheads are allowed), collector performance is dominated
> by allocator performance. In this case, copying collection and therefore
> precise collection is faster than conservative collection. In the real
> world, this is not very meaningful. I remember visiting the FOX project at
> CMU (a TCP/IP stack written in ML), the speed of collection was excellent,
> but the memory footprint of the TCP/IP stack was several tens of megabytes,
> which is completely unacceptable for a real system.

With respect, the heap requirements of the Fox projects "FoxNet" code
are not necessarily the best indication of the heap requirements of
other systems which include a copying collector.

- SML/NJ uses CPS and does not keep a stack (so it allocates out the
  wazoo). 

- until recently SML/NJ had a GC which was only generational in a
  primitive sense.

- SML/NJ does not have a tremendous "delivery" system (and as far as I
  know the Fox project does not even use the delivery mechanisms
  provided), so that "several tens of megabytes" almost certainly
  includes the SML/NJ system itself (compiler, &c), together with
  large amounts of type information &c. for the Fox code which could
  in fact be discarded at run time.

- the FoxNet project is experimental, and therefore likely to have
  (e.g. debugging) memory requirements which are not present in a
  finished product.

- the FoxNet project, at least when I was a part of it, did not place
  great emphasis on memory requirements. Thus the natural tendency of
  SML/NJ-based systems to have bloated heap requirements was not
  curbed.

Nick Barnes n'e Haines, ex-Fox, speaking for himself