[gclist] Precise GC's performance

[Mike Spertus]

> 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.
> 
Yeah, I know that you can do a lot better on space utilization with a copying 
collector than FoxNet does. I chose it especially because it was an
extreme case to show how variable space overhead can be in a collector
and the futility of ignoring it in comparing the performance of different
collectors. Specifically, copying collectors usually have the highest performance
when you are not emphasizing memory requirements, but non-experimental
apps don't have this luxury. BTW, when I toured FoxNet, the speed of memory
management was advertised to me, while the space trade-off to get it was
not. Even so, it's an impressive project that should encourage GC boosters.

> - 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
> 
>