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
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.)
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 some
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
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 get
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
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
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.
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 would
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_collect. You're
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 PMC
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 this array.
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 GC rip
Sugalski
[EMAIL PROTECTED]
04/29/2002 04:42 Subject: Re: First patch to memory
allocation routines
PM
14 matches
Mail list logo
