On Wed, May 01, 2002 at 07:15:18PM -0400, Josh Wilmes wrote:
>
> At 15:58 on 05/01/2002 PDT, Steve Fink <[EMAIL PROTECTED]> wrote:
>
> > I've applied this patch, along with fixing the original resources.c's
> > indentation (re-indenting patches are annoying, but this patch touched
> > enough of
At 15:58 on 05/01/2002 PDT, Steve Fink <[EMAIL PROTECTED]> wrote:
> I've applied this patch, along with fixing the original resources.c's
> indentation (re-indenting patches are annoying, but this patch touched
> enough of resources.c files that it seemed like a golden opportunity.)
Here are so
I've applied this patch, along with fixing the original resources.c's
indentation (re-indenting patches are annoying, but this patch touched
enough of resources.c files that it seemed like a golden opportunity.)
[EMAIL PROTECTED], Dan Sugalski
<[EMAIL PROTECTED]>
04/29/2002 04:42 Subject: Re: First patch to memory
allocation routines
On Mon, Apr 29, 2002 at 09:42:46PM +0100, Piers Cawley wrote:
> Steve Fink <[EMAIL PROTECTED]> writes:
>
> > On Mon, Apr 29, 2002 at 01:41:56PM -0400, Mike Lambert wrote:
> >> - Make an array of buffer data, in order of insertion into the hashtable.
> >> set pmc_pointer and buffer_ptr and let the
Steve Fink <[EMAIL PROTECTED]> writes:
> On Mon, Apr 29, 2002 at 01:41:56PM -0400, Mike Lambert wrote:
>> - Make an array of buffer data, in order of insertion into the hashtable.
>> set pmc_pointer and buffer_ptr and let the GC rip through it.
>> - The hashtable itself just uses indices into thi
On Mon, Apr 29, 2002 at 01:41:56PM -0400, Mike Lambert wrote:
> - Make an array of buffer data, in order of insertion into the hashtable.
> set pmc_pointer and buffer_ptr and let the GC rip through it.
> - The hashtable itself just uses indices into this array. Each
> linked-list node would be a P
> > > Btw, this is only a weak guess about what's going on, because the
> > > corruption I'm seeing isn't even in the linked list nodes. It only
> > > happens with GC_DEBUG, but it's not an infant mortality bug.
> >
> > GC_DEBUG adds extra calls to do_dod_run (infant mortality), and
> > do_collec
On Mon, Apr 29, 2002 at 01:41:56PM -0400, Mike Lambert wrote:
> > I suspect the "bug" may be in my understanding of the memory
> > management API, though. If I want to maintain a linked-list of my own
> > objects, how do I do it? If I carve out my objects (hash buckets) from
> > a Buffer, then GC
> I suspect the "bug" may be in my understanding of the memory
> management API, though. If I want to maintain a linked-list of my own
> objects, how do I do it? If I carve out my objects (hash buckets) from
> a Buffer, then GC would keep moving them around and breaking the
> ->next link pointers.
Sounds like this stuff will collide violently with my local changes.
I'm trying to track down a nasty memory corruption bug. It sounds like
it would probably be easier to find with your new version, though.
The only real changes of interest I have so far are to finish the
implementation of new_tr
Dan Sugalski wrote:
> 1) Has the external interface changed, and are you planning on having
> it change?
So far, no. mem_allocate will shortly need to be told what pool to allocate
from; but I hope to remove this function from the external interface
entirely. Other than that, it should just be the
At 4:44 PM +0200 4/29/02, Peter Gibbs wrote:
>
>Herewith the first set of patches to the memory allocation routines.
>
>There is no new functionality here yet; basically I have been working on
>trying to remove some of the code that is duplicated between the various
>pools, before even more copies
Herewith the first set of patches to the memory allocation routines.
There is no new functionality here yet; basically I have been working on
trying to remove some of the code that is duplicated between the various
pools, before even more copies get made for the new stuff.
The result is some fai
14 matches
Mail list logo
