RE: Feature request: more integration of Lua and C memorymanagement

["Virgil Smith" <Virgil@...>]

OK, here's my 2 cents...

----First issue, userdata memory management.
Lua4 kept just a pointer for userdata.  This meant that the GC didn't know
how much cost to assign to userdata (a problem for GC cycle thresholding).

Lua5 goes a step further by allocating a prestated amount of space for a
userdata.  This means that Lua gets wrapped up in the memory management
scheme for userdata which probably should have been avoided.  Also it does
not really resolve the cost of the object for GC purposes because it is
static for the lifetime of the userdata (i.e. it misses dynamic
allocations).

The answer to this is simple.  Have Lua track a "size" for the userdata and
add C API functions for updating that size.

However, I'm not sure what that will mean for the incremental GC.




----Second issue, userdata per instance Lua references

The problem here is two-fold.  Firstly, metatables are used as a means of
determining "type" information.  Having a separate metatable per userdata
instance breaks this construct, but the metatable is the only direct
reference a userdata has so any per instance Lua data must be referenced
through some other means.  This means that the per instance data will be
"rooted" through a different reference path.  Weak tables help here because
one can force the condition that if the userdata instance is GC'ed so will
its per instance data.  However, because the weak table "roots" the per
instance data, any cycle from the per instance data back to the userdata
instance will prevent the userdata from being GC'ed.

Again the answer is simple, give userdata an additional reference mechanism
besides the metatable.  Just put one more table at their disposal.




-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br]On Behalf Of Roberto
Ierusalimschy
Sent: Wednesday, June 09, 2004 12:13 PM
To: Lua list
Subject: Re: Feature request: more integration of Lua and C
memorymanagement


> I don't think any scheme with weak tables will work correctly, and it
> would be too slow anyway

Why? (for both statements...)


> That array should be accessible given only a pointer to the userdata,
> and not the actual Lua object (e.g. by storing the array immediately
> before the userdata and counting backwards).

The idea of userdata keeping direct references to other Lua objects
is nice. The original Smalltalk had something quite similar: Objects
could have an optional "raw" area plus an "array" area. But to make them
accessible given only a pointer seem dirty and dangerous. (Among other
things, how to avoid the userdata being collected?)

-- Roberto