Re: Some questions and proposals about GC and memory management in Lua

[Leo Romanoff <romixlev@...>]

>________________________________
> Von: Tim Hill <drtimhill@gmail.com>
>An: Leo Romanoff <romixlev@yahoo.com>; Lua mailing list <lua-l@lists.lua.org> 
>Gesendet: 23:59 Mittwoch, 24.Juli 2013
>Betreff: Re: Some questions and proposals about GC and memory management in    Lua
> 
>On Jul 24, 2013, at 1:09 PM, Leo Romanoff <romixlev@yahoo.com> wrote:
>
>The only drawback I would expect is that I need an additional table access every time when I need to access a Lua object. Therefore I'm not sure about the "efficient" part of my requirement.
>>My original idea was to store real references to Lua objects somewhere inside the UD. Since Lua would not know where to find those pointers inside UD,  it would need to use the __trace method from a UD metatable.
>>
>
>The trouble with this approach is the contract between Lua and C regarding memory management becomes very complex, and any issues with any C code inevitably lead to nasty hard 
> to find crashes in Lua. 

Would it really become very complex? I'm not so sure. 

But it would be more error-prone for sure, I agree, especially when written by hand. If one forgets in C code to invoke a trace method for a any of Lua objects referred from userdata, it would lead to fatal consequences. At the same time, once written such a trace method does not need to change unless you change a layout of fields inside your userdata.

Moreover, I used to implement different kinds for garbage collectors (mark&sweep, mostly copying, etc) for an extension of C/C++ called Prop in my past life. It allowed for definition of ADTs (abstract data types). You could optionally specify that a given datatype should support GC. In this case, a tool would automatically generate tracing methods based on the descriptions of ADTs and that's it. I guess a similar automation could be implemented as a separate tool for Lua, if required. 

> Python uses something akin to your request, and suffers badly as a result (the API is a horror to work with imho). 

Do you mean tp_traverse and tp_clear or something else? It would be nice if you could elaborate a bit. 

Do you mean the code like this:
static int
local_traverse(localobject *self, visitproc visit, void *arg)
{
    Py_VISIT(self->args);
    Py_VISIT(self->kw);
    Py_VISIT(self->dict);
    return 0;
}

> The Lua stack model isn't perfect, but it 
> provides a good level of protection while enabling pretty much any user scenario, 

How does Lua stack model relates to GC issues? Or do you mean that the only way to exchange data between C and Lua is to copy it via Lua stack and thus it reduces the risk of doing something wrong?

> though at a modest execution cost.

I agree that current Lua's implementation is safer as it does not rely on user-defined tracing functions and errors related to their improper implementation. But I don not quite agree regarding the "modest" execution cost. If you want to use Lua as a target language/runtime environment for other languages, performance cost introduced by indirection via a table access may be too high. For such cases, my proposed solution with a tracing method could be a faster alternative.

-Leo