Re: GC "Heisenberg" problem in latest CVS bootstrap?

"Heisenbug" = what you mean, Heisenberg = guy, where it comes from 

Cheers,
Michael

On Wed, 8 Dec 2004 18:17:10 -0800, Brian Rice <water <at> tunes.org> wrote:
> 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/
> 
>