Re: Lua's GC

[Björn De Meyer <bjorn.demeyer@...>]

RLake@oxfam.org.uk wrote:
> (royal snipping occurred)
>
> This is true. Furthermore, free(3) is called on every piece of garbage. The
> performance will be highly dependent on the implementation of free, but
> it's unlikely to be very good, since free is generally not optimised for
> garbage collection. 
/snip
> 
> What is difficult is to write such an allocator in ANSI C,
/snip

Not really. What you need to do is to do is to have your 
own custom memory allocator do a single malloc() of a huge block that
is large enough to hold all data you will be using. Then write 
your own memory management routines such that they allocate adresses 
and spaces within that one single huge block. 


A simplistic untested example:

#define MYMALLOC_SIZE 1000000 /* 1 million bytes. */

void * mymalloc(size_t * size)
{
  static size_t mytop = 0;
  static char* mybuf = NULL;
  void *result;
  if(!mybuf) mybuf = malloc(MYMALLOC_SIZE);
  if(!mybuf) return NULL; 
  if((mytop + size) >= MYMALLOC_SIZE) return NULL;
  result = (void *) (mybuf + (size + mytop) );
  mybuf += size;   
  return result; 
}

void myfree(void *)
{
  return;
  /* Do nothing, the working of mymalloc doesn't
     support frees anyway. */
}

Implementing a working myfree(), and optimising the mymalloc() 
to stop fragmentation is left as an exercise for the reader. ^_~

-- 
"No one knows true heroes, for they speak not of their greatness." -- 
Daniel Remar.
Björn De Meyer 
bjorn.demeyer@pandora.be