GC "Heisenberg" problem in latest CVS bootstrap?

[Tim Olson]

On Dec 4, 2004, at 12:46 PM, Brian Rice wrote:

> It could if there excessive slot additions and removals at some point. 
> I haven't profiled anything to look for this, but numeric.slate's 
> source itself has no abnormal number of such slot manipulations (26). 
> I don't think the lexer, parser, or compiler do this kind of thing 
> dynamically, either.

I don't think there is anything special about "numeric.slate", other 
than it is large (so it shows up dramatically when it takes a long time 
to process), and during my build that's where the free space drops to a 
very small size.   During processing it spent > 90% of its time in 
garbage collection, but GC always found enough free that it didn't 
trigger a heap growth.

To test the idea that it is simply the free space (or more precisely, 
the lack thereof) that is causing this, I performed a large dummy 
allocation just before the bootstrap build:

	Array newSize: 5000000.

The build went much faster; in particular, processing of 
"numeric.slate" was easily 10x faster.

After a number of builds I've not seen a segmentation violation like I 
saw a couple of times during the "slow" build, so I've not been able to 
track down the root cause of that, but I suspect that it was caused by 
some strange condition during the excessive GC.

I think Attila Lendvai's suggestion of triggering early heap growth 
when the free space reclaimed drops below a particular level is a good 
one.

	-- tim