RE: Thinking about Lua memory management

["Joshua Jensen" <jjensen@...>]

> > Are you planning to move objects?
> 
> No... Among other problems, GC can happen while C code keeps 
> pointers to strings inside Lua.

I say this is too bad.  They should lua_ref() the object if they want it
to keep it.  There is no guarantee the pointer in the C code will be
good anyway, since Lua could have garbage collected it.

> Moreover, Lua does a lot of 
> realloc's, so to compact memory too tightly for some arrays 
> may not be a good idea.

I would bet that in the majority of allocators out there, the memory
manager has to completely move the block of memory anyway to get the
space it needs.  This leaves a nice hole in the middle of memory, it is
the reason why I added the ability to predefine table sizes.  That's a
subject for another email, though.

A handle based approach to Lua's memory would be very beneficial in my
opinion, at the expense of an extra pointer dereference to access the
data.  I don't honestly believe the speed hit would be too bad, and it
would potentially increase the long term stability of Lua a hundred
fold, since objects could be collected to the bottom of the heap.
Fragmentation would become a moot point.

This is where a C++ smart pointer is highly useful, since it can
completely mask the handle based pointer lookup.  Or it's policy can
just store the pointer and no lookup is incurred.  The user could choose
the policy he/she wanted.

Of course, this isn't acceptable in ANSI C, but it is an interesting
approach to the issue.

Thanks,
Josh