At 6:37 AM -0400 4/14/02, Mike Lambert wrote:
>Bryan C. Warnock wrote:
>
>> Oh, in which case, I agree with you. ;-)
>
>Oh, woops. :) For some reason I was assuming you were arguing against
>my patch.
Which is applied. I'd rather enforce the "No allocations until
mem_setup_allocator is done, a
Bryan C. Warnock wrote:
> Oh, in which case, I agree with you. ;-)
Oh, woops. :) For some reason I was assuming you were arguing against
my patch.
Anyways, below is a revised and simpler patch that implements the same
semantics as before, but using Dan's new DOD_block_level and
GC_block_level
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 wh
> 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 *d
On Friday 12 April 2002 03:22 am, Michel J Lambert wrote:
> > > So you're saying that the calls to get memory during interpreter
> > > initialization are somehow guaranteed to not require more memory (and
thus
> > > a dod or collection run)? Currently, this guarantee is not expressed in
> >
> > I
"Michel J Lambert" wrote:
> Below is a patch which allocates the pools from system memory.
> Unfortunately, it doesn't seem to provide any noticeable speed gains. I
> get anywhere from a -1 to 15 extra generations per second. Current results
Even though we copy large amounts of memory around, ve
> The current design never shrinks the free header pools, and indeed there is
> probably little point in doing so, so nothing seems to be gained from
> including them in the collection process.
>
> Using my favourite 5000-generation life.pasm as an example:
> A total of 10930 collection runs were
n C. Warnock" <[EMAIL PROTECTED]>
Cc: "Dan Sugalski" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: 12 April 2002 09:22
Subject: Re: [PATCH] Disable GC at startup
> > > So you're saying that the calls to get memory during interpreter
> > > initia
> > So you're saying that the calls to get memory during interpreter
> > initialization are somehow guaranteed to not require more memory (and thus
> > a dod or collection run)? Currently, this guarantee is not expressed in
>
> I don't understand the "thus." Nothing states that requesting memory
On Thursday 11 April 2002 07:03 pm, Michel J Lambert wrote:
> Dan Sugalski wrote:
> > That's because GC_DEBUG is fundamentally broken by design. It's doing
> > things it shouldn't be doing--the system is such that it shouldn't
> > ever trigger GC before the memory allocation system is set up.
> >
Dan Sugalski wrote:
> That's because GC_DEBUG is fundamentally broken by design. It's doing
> things it shouldn't be doing--the system is such that it shouldn't
> ever trigger GC before the memory allocation system is set up.
>
> If this patch disables the GC only when GC_DEBUG is in place, I'll p
At 5:35 PM -0400 4/11/02, Michel J Lambert wrote:
>There are still plenty of problems with GC_DEBUG turned on, but at least
>it passes all the non-pmc tests now. Has anyone done anything with
>attempting to get a make tinder and tindertest set up?
That's because GC_DEBUG is fundamentally broken b
12 matches
Mail list logo
