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.