Re: object addresses in Lua

[Xingzhi Pan <vengeance.storm@...>]

Thanks for the detailed reply.  I have further questions inlined below.

On Fri, May 27, 2011 at 11:44 AM, Robert G. Jakabosky
<bobby@sharedrealm.com> wrote:
> 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.

I don't quite understand "The pointer...are used in the hash value
when they are used as keys in a table”.  So you're saying for example
when a function is used as a key in a table, its pointer is used "in
the hash value"?  What does "in the hash value" mean here?  I suppose
this function, as a key, can be used to retrieve a value (e.g., a
string) from the table.  According to you, how is this value connected
to this function's pointer?

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

Please define "rehashing".  It seems that you're saying adding another
level of indirection but I'm confused.

>
>> 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 guess I need to read more about ltable.c to understand how objects
are connected together in a Lua VM instance.  But thanks to you I
already at least realized that they are mainly interconnected via
tables.  A little pointers would be appreciated.

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

Since I'm doing a semi-space copying collector, the allocator will
always allocate memory from one end of a semi-space.  I do need to
think about variable-length objects, though.  Thanks for the help
again!  I know you are the author of the emergency garbage collector
:-)

>
> --
> Robert G. Jakabosky
>