Alan Kay wrote:
> 
> Interval had a great submillisecond GC that was terrific for
> real-time apps. Maybe we can get this from them now that they have
> donated their work to Stanford (per Glenn Edens).
We (in practical terms, Craig & I) were given permission to release all
the applicable Squeak stuff ages ago. With luck the tranche of stuff
handed to Stanford might include a copy of the lost GC code; we've never
been able to find a copy anywhere. 

It wasn't so much a sub-millisecond GC as a constant slow-drip GC. It's
along time ago, but as I recall it involved every object header having a
forward and backward pointer. Basivally, 'killing' an object involved
moving it from the live double linked list to the dead one - changing 4
pointers. This of course does not handle compaction and I think we
concluded that for most of the purposes we were interested in there was
very little need to worry about it too often. Buit why am I blathering
about it - Paul McCullough reads this and can surely explain much more
since he lead that sub-project.

The other important aspect of the real-time nature of the Interval
system was the combined Squeak/native process scheduling that allowed
interrupt handlers to be written in Squeak. Oh, and of course the
reduced latency changes. I would note that we had the luxury of not
having some dumbf&*k OS in the way to cause problems. As soon as some
nincompoop had the bright idea of using a 'proper OS' (winCE in this
case) it all went to hell.


> 
> Don't forget that the current GC (and any Squeak GC) has to handle
> real time demands for animation and music, etc.
Exactly; making sure that that works almost always exacts a cost in
aggregate performance. The Interval system was really pretty slow
becasue of all the work it had to do to make sure it was possible to
'change its mind' at a microseconds notice.

Optimisations for straight run code are often going to slow down
heterogenous situations (this also involved in the perennial debate
about typing and performance), big caches seem great in benchmarks
designed to show the benefits of caches but look a bit lame in very
variable code (viz Sparc register windows - look wonderful until you
have to change context), adding memory seems great until you have a
potential customer that wants to run in 8Mb.

tim