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
13 matches
Mail list logo
