Re: Garbage collector issues

[Edgar Toernig <froese@...>]

Roberto Ierusalimschy wrote:
> 
> > One solution could be something like:
> >
> > LUA_API void lua_userdatasize(lua_State *L, size_t size)
> >
> > which would assign the given size in bytes (to the GC) to the userdata
> > situated on top of the stack.
> 
> You can implement this function as follows (I gess ;-):
> 
> /* in lapi.c */
> LUA_API void lua_userdatasize (lua_State *L, size_t size) {
>   if (ttype(L->top-1) != LUA_TUSERDATA ||
>       tsvalue(L->top-1)->len != 0)
>     lua_error("...");
>   tsvalue(L->top-1)->len = size;
>   L->nblocks += size*sizeof(char);
> }

Don't you think that this (below) will be much simpler and more
versatile?

LUA_API void
lua_gcaccount(lua_State *L, long amount)
{
    L->nblocks += amount;
}

That way, C code may tell the GC how many bytes to consider exported
by the C part.  amount will be negative when freeing space.
Coroutines for example may want to notify about the C stack allocated
to each thread.

There are a lot of places where L->nblocks is modified.  Wouldn't
it be easier to let luaM_malloc do that?  Of course, luaM_free
would require a size argument, too.  But this value is always known.
(Well, your patch above will break it *g*)  Aside from that, there
are architectures that could benefit from a free with a second (size)
argument.

Ciao, ET.


PS: Btw, lua_newuserdata and co are IMHO slightly broken:

> print(dostring"")  -- gives lua_pusheruserdata(L, NULL)
userdata(0): 0x80632b0
> print(dostring"")
userdata(0): 0x8063448 -- and another one?!?

Maybe this change

-  ts->u.d.value = (udata == NULL) ? uts+1 : udata;
+  ts->u.d.value = s ? uts+1 : udata;

would make a little bit more sense.  (There are other
problems too.  Still thinking about a solution.)