On Friday 12 April 2002 08:21 am, Michel J Lambert wrote:
> > 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.
Oh, in which case, I agree with you. ;-)
>
> 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
I was referring to the pathetic situation where initialization really would
run out of memory. (Not simply fill up the initial allocation buffer, but
is unable to allocate any more memory from the system.) Going back and
DOD/GC may then give you enough room to finish initialization, but probably
not enough to do anything useful, so I don't see that as a reason to run GC
then, either.
--
Bryan C. Warnock
[EMAIL PROTECTED]
