Lua's memory management was RE: Lua's GC

[Pyrogon Public <public@...>]

Thanks for all the pointers.

How is Lua about memory fragmentation?  Not actual memory fragmentation,
but the more relevant (these days) concerns of address space
fragmentation?

This could be somewhat offset if Lua (as suggested by someone else)
allowed you to trivially hook in your own memory manager that supplies
arenas for each Lua VM (but you'd still have potential fragmentation per
VM).

For example:

The main game engine has multiple Lua entities, and decides that to
reduce its own memory fragmentation, each Lua object gets its own Lua VM
instance (which don't communicate with each other directly), which
allows the various objects to be sandboxed.  But at the same time, it
wants to limit the memory available to each VM to, say, 512K.

So some object has a 512K heap to work with.  Internally it's doing a
lot of object creation/deletion, with objects in size from tiny (32
bytes) to fairly large (say, 16K).  Object life expectancy is fairly
random and unevenly distributed.  After a short period of time, it's
quite likely that the 512K address space is now fragmented into lots of
small pieces, even though the GC has guaranteed that there is a good
chunk of heap space left -- just not all contiguous.

The obvious solution to this problem is to make sure that all internal
references are indirect (i.e. a table identifier is NOT just a memory
address) so that compaction can be done trivially.  Is this what Lua
does right now, or am I completely confused on this subject?

Brian