[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: object addresses in Lua
- From: "Joerg Walter" <joerg-walter@...>
- Date: Tue, 31 May 2011 12:16:47 +0200
This touches my question regarding table identifiers.
As I understand it these pointers identify especially tables uniquely.
So when I have
g =
{
y = 1,
z = 2
}
a =
{
b =
{
w = 200,
x = 300,
ref = g
},
v = 100
}
I get different pointers for a,b and g. The pointer for ref would hopefully yield the pointer for g?
-------- Original-Nachricht --------
> Datum: Tue, 31 May 2011 01:32:01 -0700
> Von: "Robert G. Jakabosky" <bobby@sharedrealm.com>
> An: Lua mailing list <lua-l@lists.lua.org>
> Betreff: Re: object addresses in Lua
> On Monday 30, Xingzhi Pan wrote:
> > 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?
>
> "in the hash value" should have been "as the hash value". Basically I was
> saying that the pointer is used to create the semi-unique hash value for
> complex Lua objects. For string keys a hash function is used to convert
> the
> string's contents to a semi-unique hash value.
>
> > 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?
>
> The Lua code below shows how a function value is used as a key:
> local tab = {} -- some table
> tab[print] = "some value"
> print(tab[print]) -- print value store in previous line.
>
> Lua needs to be able to lookup that key in the internal hash part of the
> 'tab'
> table, to do that Lua needs to be able to hash the key (convert it to a
> semi-
> unique number) to find the first bucket where that value might be stored.
> For
> values that are not a string/number/boolean Lua uses the pointer to that
> value
> as the hash when doing that lookup.
>
> > > 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.
>
> Rehashing means to find all keys in all tables that used the old pointer
> (the
> old hash), which will need to be removed and then re-inserted using the
> new
> pointer (the new hash).
>
>
> > >> 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.
>
> Yes, I recommend that you understand what the code in ltable.c does.
>
> Vaughan McAlley, has provided more info about how hashtables work, which
> you
> will need to understand before you try to understand the hashing code in
> ltable.c.
>
> --
> Robert G. Jakabosky
>
--
NEU: FreePhone - kostenlos mobil telefonieren!
Jetzt informieren: http://www.gmx.net/de/go/freephone