[gclist] Precise GC's performance

[Nick Barnes]

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

Yes, but until very recently, the FoxNet was using SML/NJ 0.93, which
I think does not have Zhong Shao's work.

> Also, most of the return continuations are extremely short lived, so
> they have little impact on the memory footprint.

Yes and no. Allocating a huge number of very ephemeral objects (the
continuations) increases the frequency of collections and therefore
increases the proportion of other short-lived objects which are still
alive at GC time. When you take ephemeral allocation to the limit (as
SML/NJ did), this effect is observable. When you further have only 1.5
generations (as SML/NJ did), these short-lived objects get promoted
into "oldspace", and thereafter have the same status as all long-lived
objects. Sure, they'll get collected at the next "major GC", but they
have a footprint. So your "oldspace" needs to be larger.

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

That long already! Doesn't time fly. I apologize if I gave any other
impression. Certainly your collector is a significant improvement. I
am fairly sure that 0.93 still had the old collector, and the FoxNet
was using that until very recently. They were almost certainly using
it when Mike Spertus saw the system.

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

I think this is just what I said. When I worked on Fox, they did not
use exportFn, because memory size was not an issue (as I explained in
my earlier message). Wasn't it 0.93 that leaked the compiler into
exportFn images in any case?  Or was that 0.75? 

I didn't realize you still had that compilation unit problem. That
bugged me from the first time I ever used SML/NJ....

Nick Barnes, speaking for himself