GC "Heisenberg" problem in latest CVS bootstrap?

[Brian Rice]

Thanks for the analysis. This does seem mostly correct. Lee, any 
comments or ideas on design improvements?

On Dec 4, 2004, at 6:37 PM, Tim Olson wrote:
> 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.

--
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/