lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Thursday 26, Xingzhi Pan wrote:
> Hi,
> 
> We all know that tables, functions, threads, and (full) userdata are
> objects in Lua.  I'm wondering how the addresses of such objects are
> treated in the Lua runtime system.  In particular, I want to know how
> hard it is (or possible at all) to modify the Lua VM so that these
> addresses can change at runtime without breaking the execution of the
> running Lua program.

The pointer for some Lua values (lightuserdata,userdata,table,function,thread) 
are used in the hash value when they are used as keys in a table.  Either you 
will have to change how those values are hashed, or you will have to re-hash 
all values that you move.

One way to handle the rehashing is to replace the old GC value with a 
redirect/link value, which contains a pointer to the new location.  Then 
during garbage collection you can re-hash all link values to the new value.  I 
haven't read much on compacting GCs, so there might be a better way of 
handling this.

> The motivation behind this question is that I'm playing with Lua's
> incremental mark-and-sweep garbage collector and am wondering if it's
> possible to replace it with a moving collector (e.g., a copying
> collector).  This is a personal project aiming at learning GC and
> having fun.

You might want to start by classifying each allocation as movable/non-movable.  
Some allocations (node arrays in tables, the internal string table) can be 
moved/reallocated without having to do a lot of fix-ups.

I would also recommend adding a hint parameter to the Lua allocator.  The 
hints would tell the allocator if the object is fixed-length (i.e. 
structures), variable-length (i.e. resizable arrays), or movable.  These hints 
would help the allocator decide where to place the allocation to help prevent 
external fragmentation.

-- 
Robert G. Jakabosky