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
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,
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 made
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, very
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
mandates
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
initialization are somehow guaranteed to not require more memory (and
thus
a dod or collection run)? Currently, this guarantee is not expressed
in
I
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 don't
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*,
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
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.
If
The attached patch disables GC at startup. If you turn on GC_DEBUG, you'll
see parrot crash at startup because dod runs and collection runs are being
performed before the interpreter is fully initialized, causing all sorts
of havoc.
This also means that if our default GC allocation values do not
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 by
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 put
13 matches
Mail list logo
