GC "Heisenberg" problem in latest CVS bootstrap?

[Brian Rice]

Uh, the consensus is that this is a good idea. I'll accept any 
reasonable patch in this direction.

On Dec 5, 2004, at 1:06 PM, Brian Rice wrote:

> 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/
>
>
--
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/