[gclist] Precise GC's performance

[John H. Reppy]

In message <12166.826128948@harlequin.co.uk>, Nick Barnes writes:
>
...
> 
> 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). 

Zhong Shao's work has reduced this by about 50%.  Also, most of the return
continuations are extremely short lived, so they have little impact on the
memory footprint.

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

Dependes on your definition of "recent."  We've been using my generational
collector for about 2.5 years.

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

While there is much room for improvement, an exportFn image is getting close to
being a reasonable size, and will not include the compiler.  The main problem
is the size of the exported code regions, and this won't be fixed until we can
break compilation units into multiple code objects.  The baseline exportFn image
is about 220Kb of code and 9K of data.  I think the problem the FoxNet suffers from
is that they use an old version of the system (with the old GC I think).

	- John
	  AT&T Research.