GC "Heisenberg" problem in latest CVS bootstrap?

[Lendvai Attila]

:: When I did the second-level bootstrap process on the most 
:: recent code 
:: (build a vm & image, then use those to build again), I find that the 
:: second-level build gets slower and slower,  hanging when parsing 
:: numeric.slate and dying with a segmentation violation.  
:: Using the Shark 
:: performance tool I see that it is spending nearly all of its 
:: time in GC 
:: (markAndPushSlotsOf, findNextFree, pinCards), and less than 
:: 1% of its 
:: time in interpret, just before it dies.

If there was a way to count free heap size at a full GC then there
should be some check to early-grow the heap when it gets around 70% or
so...
I've been looking at the GC code for a few minutes but I need even
further reading on GC's first... :)

:: However, if I add a debug print to lexer.slate to show the 
:: line number, 
:: the second-level bootstrap process completes successfully.  
:: Seems like 
:: a Heisenberg somehow related to GC.

I did experience once or twice that doing an error-free bootstrap with
my custom vm/image resulted in a crashing vm/image. And doing the
process with the alpha vm/image from the same codebase resulted in a
working vm/image...

Now this could have been due to mixing up images, because it's fatal and
there's no check to prevent it currently, but it could have been due to
some strange sideeffects trough bootstraps...

- 101