[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: object addresses in Lua
- From: "Robert G. Jakabosky" <bobby@...>
- Date: Fri, 27 May 2011 11:44:51 -0700
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