A Suggestion about Lua Memory Compaction

["Peter Hill" <corwin@...>]

Having looked more thoroughly at the situation I realise the naivety of
wanting Lua to perform memory compaction.

Lua uses the standard "alloc / free" type calls which it _shares_ with the C
host code. As such, memory is also potentially fragmented *between* the host
program and Lua modules.

For Lua to be able to perform memory compaction it would be required to
allocate all its memory from its own pool... and I don't think this is
likely to be considered desirable ;-P.


What this means is that, in practice, implementing memory compaction is left
up to the *C program* (should it desire to do so) while Lua is merely
required to *support* the host program's compaction choice.

To provide this support Lua needs to add two features...

(1) a new function, "lua_adjust(LuaState)", which adjusts all internal
pointers in the Lua state (including hash tables, closures, etc) to their
new post-compaction values. It does this via calls to 'adjust()', an extra
memory manager function that is used like "new_memory = adjust(old_memory)".

The function 'lua_adjust' is so closely tied to Lua's internal structure
(which may vary from version to version, including betas) that it should
probably be considered as a part of the official source. Note, however, that
this function only needs to be linked into the Lua executable IF the host
intends to use compaction; otherwise it adds no memory overhead to the
existing system.

(2) as 'userdata' may carry internal pointers (understood only by the C
host) an extra "__adjust" metamethod needs to be provided so that the C
program can adjust such pointers. Once again this feature need only be
compiled in (with #ifdef etc) if compaction support is desired in the final
executable.

*cheers*
Peter Hill.