> I thought the point of the discussion was turning off the GC until such time
> that it was ready to go. I know what it *does* - what should it *do*?
>
> {Rest of the comments snipped.}
I don't know quite what you mean by what 'should it *do*'? *do*, as in
what it should do with my patch? Or *do*, as in do what dan thinks it
should? Or something else? As such, below is just me rehashing what I've
said before, but hopefully in a clearer manner.
My patch *did* turn off the GC until it was ready to go. Dan said that
this wasn't necessary, since GC_DEBUG was the case that caused dod and
collection runs to occur during initialization. My response was to point
out that we're currently 'lucky' that we have enough memory to complete
the interpreter initialization. Magic numbers, as 32768 happens to be
bigger than 3 arenas of 1024. If/as more stuff starts occuring during
initialization, we might overflow our magic number 32768 and cause
problems.
You stated (at least my interpretation of what you stated was) that if we
can't provide enough memory to startup without causing a collection run,
we shouldn't bother starting up at all. If we didn't have enough memory to
start up, then I'd agree with you. But, since we give out requests from
whatever we initially allocate, THEN do a collection run, and THEN
allocate more, it's perfectly possible to request more memory than we have
allocated at the time, and Parrot *should* go and get more. Currently, if
this situation happens during initialization, Parrot will crash.
Mike Lambert
