At 7:55 AM -0800 2/18/02, 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).
>
>Don't forget that the current GC (and any Squeak GC) has to handle 
>real time demands for animation and music, etc.

Alan's point goes directly to the heart of the GC tradeoff: if you want to minimize
the total GC overhead, and you don't mind a GC running for a few hundred milliseconds,
then the number of allocations between GC's can be set to a high number, as Scott
showed in his experiment. If, on the other hand, you're generating 20 or 30 voices
of music in real time while doing animation, you want to break the GC work into
chunks too short to be noticable, say under 10 milliseconds. In this case, you're
willing to let the GC do more total work in order to avoid noticable pauses. One
might call this the "proactive" approach to garbage collection.

Different applications benefit from different settings, which is one reason the
parameters can be changed at run time. (The other reason is to allow experiments
such as the one Scott just performed. :-)) The current defaults were set to allow
smooth real-time multimedia on a 100 MHz PowerPC or equivalent. Because
Squeak was developed for a community of teachers and children, we believed
(and still do) that the default settings should support multimedia even on older
machines. Now that many schools are upgrading to iMacs, it might be worth
increasing the defaults a little, or, as John Mcintosh suggested writing some
startup code that automatically sets the GC parameters to values that support
low-latency GC's.

The Interval Squeak VM had a custom incremental collector based, I think,
on the Train algorithm. I believe their GC also used more processor time
in GC overall, but it allowed for such low latency that one could actually
write interrupt handlers for hardware devices in Squeak. I'm sure Tim can
supply more details if you're interested!

Scott's experiments show that there's a factor of three in GC overhead between
the current parameter settings and an extreme setting when Squeak has 500 MB of
real memory available. It would be interesting to plot some of the points in between
for the same set of benchmarks. Is it a linear relationship or is there a "knee"
in the curve? This data might help John Mcintosh with his idea of adaptively
setting the GC parameters at startup time.

	-- John

P.S. By the way, RAM prices have gone back up. You can no longer get 512 MBytes
for under $100. There was apparently a price war going on late last year. But it's
still incredibly cheap compared to a few years ago.