John M McIntosh writes:
 > Yes, but what would that buy you? For example lets look at the image  
 > I'm currently
 > editing
 > 
 > uptime			1h39m29s
 > memory			38,573,136 bytes
 > 	old			34,237,936 bytes (88.8%)
 > 	young		168,148 bytes (0.4%)
 > 	used		34,406,084 bytes (89.2%)
 > 	free		4,167,052 bytes (10.8%)
 > GCs				13,757 (434ms between GCs)
 > 	full			5 totalling 3,836ms (0.0% uptime), avg 767.0ms
 > 	incr		13752 totalling 60,476ms (1.0% uptime), avg 4.0ms
 > 	tenures		32 (avg 429 GCs/tenure)
 > 
 > 13,757 youngspace GC events, but only 5 full (aka OldSpace) collections.
 > If you hide the 3.836 seconds by mixing it in with other processing  
 > over the hour & 40  minutes my image has been running I certainly won't  
 > notice anything.

It's not the total 3.8 seconds that need to be hidden but the 0.767
seconds for an individual global GC. 0.767 seconds is a long time if
you're using Squeak as a musical instrument.

GC takes 20% of the time when running at 100% CPU. If Squeak was 3.4
times faster (Exupery's current bytecode benchmark performance) that
would mean over 40% of the time was going into the GC. At that point
it would be worthwhile overhauling the GC for uniprocessor
performance. If it's worthwhile overhauling the GC then looking at
ways to provide other benefits without too much extra work is
sensible.

This is very long range planning, I don't plan to do anything for at
least a year or two but it's still nice to know what the options are
with their costs and benefits. Doubling Exupery's current performance
without improving the GC performance will have limited returns.

Mostly concurrent GCs would be helpful for personal multimedia use
where short pauses matter and for large server applications where a
full GC takes more than a few seconds. Multiple interpreters could be
added fairly easily by providing each one with it's own new space
(ignoring any issues in the image).

Bryce