[gclist] Precise GC's performance

[Nick Barnes]

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

Well, the space trade-off is not made to get fast memory
management. The space trade-off is made to get SML/NJ [0.93], which is
(or was) the right tool for the FoxNet job for various reasons
(principally because the compiler sources were available and familiar
to some of the Fox people -- Greg Morrisett in particular).

You get the fastest allocation by allocating linearly into large free
blocks, and by having your own compiler so you can keep the allocation
state in registers. A copying collector will give you the free blocks
(although as traffic here has shown, other approaches will do it too).
You get fast automatic memory management by having a good GCed
system. Copying collectors can fit this description.

I'm surprised the Fox people spoke about the runtime speed of memory
management. It was not considered that important when I worked
there. The software engineering advantages of automatic memory
management, on the other hand, are an important part of what the Fox
project is about.

Nick B