[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: object addresses in Lua
- From: Xingzhi Pan <vengeance.storm@...>
- Date: Mon, 30 May 2011 22:35:44 -0700
Thanks for the detailed reply. I have further questions inlined below.
On Fri, May 27, 2011 at 11:44 AM, Robert G. Jakabosky
> On Thursday 26, Xingzhi Pan wrote:
>> 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