[gclist] Prior work?

[Charles Fiterman]

At 01:58 PM 2/9/00 -0500, you wrote:
>
>Thanks, for all the feeback. For this particular application the specialized
>scan function is there for type safety reasons, improved performance isn't
>the actual goal. I just noticed a small benchmark with an explicit scan
>function beating the obvious C version, and was wondering if for more
>realistic systems building an explicit scan function is going to be a
>performance win or not. I guess, I'll just have to run an experiment on a
>large system to see what happens.

My guess is that cache behavior will swamp other considerations and since
interpreting bitmaps is the densest it will be the fastest except for
extreme cases like large stacks.

But this will change and change soon. Caches create heat and the newest
chips like the Itanium don't have caches they have smart pipelines and
multi processors. Since wires now dominate chip surface and copper has
replaced aluminum for wires, cache memory is going to vanish in the near
future. On a cacheless machine the specialized scan function will obviously
win. 

I've just realized that if you have a doubly linked list the specialized
scan function could not only ignore the back pointer it can do a depth
first non return scan of the list.

What is right must be a collector that is very different for different
machines. I could easily see radically different collector organizations on
different versions of 80x86.