Desperately off-mailing-list-topic. I'll stop now. Re: Lua's GC

[RLake@...]

> 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:

... snip ...

Maybe I should have said that it is difficult to write a non-simplistic
allocator in ANSI standard C. Of course, it is difficult to write a
non-simplistic allocator period, so I guess that's tautological.

Perhaps you are right... However, I usually find myself optimising
allocators based on my knowledge of word size, alignment constraints,
and other factors which one has to mark as "Warning: porting required"
(like the availability of mmap options).

The strategy of allocating one single block which is big enough for
anything you might need is certainly perfectly adequate for an
embedded environment, and may work well on VM environments, if you
can actually predict in advance what that size should be. It's
certainly a valid option.

Allocation in a VM environment is significantly different from
allocation in a non-VM environment... I'm a little skeptical of
the possibility of writing a really great allocator that is
VM agnostic.