• Jarrett Billingsley (34/34) Jun 10 2005 I combined the free list and custom new and delete examples in the "Memo...
• Derek Parnell (16/23) Jun 10 2005 It doesn't interfere with the GC and so that should be fine. The way you
• Jarrett Billingsley (5/16) Jun 11 2005 Thanks for the reply. One question though - what exactly is a "low on R...
• Vathix (1/2) Jun 10 2005 It's valid to delete null so you should check for it.
• Jarrett Billingsley (3/5) Jun 11 2005 Good point.
• Dave (10/44) Jun 13 2005 You could replace the call to malloc with this:

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

I combined the free list and custom new and delete examples in the "Memory 
management" section of the D docs to do this:

class A
{
 new(uint sz)
 {
  void* p;

  if(freeList)
  {
   p=cast(void*)freeList;
   freeList=(cast(A)p).next;
   writefln("got from list");
  }
  else
  {
   p=std.c.stdlib.malloc(sz);
   if(!p)
    throw new OutOfMemoryException();
   addRange(p,p+sz);
  }

  return p;
 }

 delete(void* p)
 {
  (cast(A)p).next=freeList;
  freeList=cast(A)p;
 }

 static A freeList;
 A next;
}

This seems to work fine, as I put logging in these functions and it works 
correctly.

However, I'm not sure if overloading the delete is such a good thing.  It 
never deletes any of the memory.  Will this interfere with anything? 

Derek Parnell <derek psych.ward> writes:

On Fri, 10 Jun 2005 21:22:57 -0400, Jarrett Billingsley wrote:

 I combined the free list and custom new and delete examples in the "Memory 
 management" section of the D docs to do this:

[snip]

 This seems to work fine, as I put logging in these functions and it works 
 correctly.
 
 However, I'm not sure if overloading the delete is such a good thing.  It 
 never deletes any of the memory.  Will this interfere with anything?

It doesn't interfere with the GC and so that should be fine. The way you
are doing this implies that after any given delete, it is possible for a
create to happen. Given that scenario, this algorithm is okay. 

You might want to add a special routine that literally frees up RAM and
resets the free list pointer, if you ever get to the point where you know
that you are never going to create any more items and there are no items
remaining, and the application is continuing to run.

Another possibility is a function to sweeps through the free list and
deallocate RAM *and* resets the free list. This might be useful if you ever
get a low-on-RAM signal.

-- 
Derek Parnell
Melbourne, Australia
11/06/2005 11:21:06 AM

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"Derek Parnell" <derek psych.ward> wrote in message 
news:43qqnhicdszv.doc3g233sqgl$.dlg 40tude.net...
 It doesn't interfere with the GC and so that should be fine. The way you
 are doing this implies that after any given delete, it is possible for a
 create to happen. Given that scenario, this algorithm is okay.

 You might want to add a special routine that literally frees up RAM and
 resets the free list pointer, if you ever get to the point where you know
 that you are never going to create any more items and there are no items
 remaining, and the application is continuing to run.

 Another possibility is a function to sweeps through the free list and
 deallocate RAM *and* resets the free list. This might be useful if you 
 ever
 get a low-on-RAM signal.

Thanks for the reply.  One question though - what exactly is a "low on RAM 
signal" and how do I check for it?  Is it something I can check for with the 
GC? 

Vathix <vathix dprogramming.com> writes:

  delete(void* p)

It's valid to delete null so you should check for it.

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"Vathix" <vathix dprogramming.com> wrote in message 
news:op.sr6ngcihkcck4r esi...
  delete(void* p)

 It's valid to delete null so you should check for it.

Good point. 

Dave <Dave_member pathlink.com> writes:

You could replace the call to malloc with this:

//          p = std.c.stdlib.malloc(sz);
//          if(!p)
//              throw new OutOfMemoryException();
//          addRange(p,p+sz);

p = new void[sz];

Then the GC should reclaim that memory.

Maybe something to add under the memory management docs.?

- Dave

In article <d8de28$2d61$1 digitaldaemon.com>, Jarrett Billingsley says...
I combined the free list and custom new and delete examples in the "Memory 
management" section of the D docs to do this:

class A
{
 new(uint sz)
 {
  void* p;

  if(freeList)
  {
   p=cast(void*)freeList;
   freeList=(cast(A)p).next;
   writefln("got from list");
  }
  else
  {
   p=std.c.stdlib.malloc(sz);
   if(!p)
    throw new OutOfMemoryException();
   addRange(p,p+sz);
  }

  return p;
 }

 delete(void* p)
 {
  (cast(A)p).next=freeList;
  freeList=cast(A)p;
 }

 static A freeList;
 A next;
}

This seems to work fine, as I put logging in these functions and it works 
correctly.

However, I'm not sure if overloading the delete is such a good thing.  It 
never deletes any of the memory.  Will this interfere with anything?