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

[Tim Hill <drtimhill@...>]

> 
> 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.

Well complexity of course is in the eye of the beholder. However, it would involve a radical switch. In the current model the internals of Lua memory management are insulated from C code via the Lua stack abstraction; you never directly get a pointer or reference to any Lua data values. This means the opportunities for C code to mess up the Lua state are significantly reduced. As soon as you add any form of shared GC responsibility you flip into a different model entirely.

>> 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. 

I agree, but it's been so many years since I worked in Python, and like all unpleasant experiences I blanked it out of my mind :)

> 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?

Exactly. There is never an issue about ownership of memory, or needing to do strange locking or marking (even with userdata). While this is technically less efficient since some redundant copies can occur, the added robustness seems worth it imho.

> 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.

Have you quantified that cost? It would be interesting to try to compare different approaches to see.

--Tim