[gclist] Time-stamping objects...

[Charles Fiterman]

> |   Generational collectors eliminate fragmentation and if you have enough
> |   storage are more efficient. In fact as the amount of storage increases
> |   copying collectors approach zero overhead. If you never reach the end
> |   of the space copying collectors have zero overhead. With this in mind
> |   it makes sense to build execution frames on the heap.
> 
> You have to be very careful about this last claim because it is
> generally not true.
> 
> The add/subtract instruction that deallocates a stack frame
> simultaneously produces the pointer to the previous one.
> 
> If you allocate execution frames on the heap you will typically have
> to load through a pointer to obtain the pointer to the previous one.
> In addition, depending on your allocator you may need to write extra
> header words (e.g. length of frame).
> 
> Thus even if you never trigger a collection, you will typically have
> higher overhead for the heap-allocated execution frames than for the
> stack-allocated frames.
> 
> A different issue is how expensive is call-with-current-continuation
> and which way the trade-off should go there.

I'm experimenting with a system where execution frames are full
blown objects that can take a variety of messages. Once this level
of sophistication is reached a lot of execution frames become
complex and you have fewer execution frames. Partial evaluation
makes a lot of messages non frame building. You can evaluate down
to inline code or even a result.