Re: LuaJIT and keeping objects alive

[Roberto Ierusalimschy <roberto@...>]

> I haven't started using LuaJIT yet, but I have been working with some
> design patterns that I wonder whether could still be relied on there.
> 
> For instance, if I do this:
> 
> local bar
> 
> local function foo()
>     local U = newproxy(true)
>     getmetatable(U).__gc = function(self) print "goodbye world" end
>     return bar(U)
> end
> 
> function bar(U)
>     ...lots of processing that might force a garbage-collection...
>     ...nowhere here do we do anything with U...
> end
> 
> In straight Lua, U will still be alive during the execution of bar, so
> it won't be gc'd until after bar returns. Could that still be relied on
> in LuaJIT? Or might the JIT compiler see that U is never touched inside bar,
> and optimize foo's tail-call in such a way that U is no longer
> referenced by anybody once control switches to bar?
> 
> I realize there are work-arounds. For instance, one could change foo so
> that the call to bar was no longer a tail-call. Or one could keep U
> alive during bar's execution in another way (what I ended up doing). I
> just suspected this might be something I'd need to attend to when using
> n optimizing compiler.

A finalizer should be callable at soon as its corresponding value is
disposable. You should not consider whether there is still a pointer to
the value, but whether the value is going to be (really) used again.

If you are not going to use U again, Lua (or LuaJIT or whatever) should
be able to call its finalizer without interfering with the correctness
of the program.  Maybe you should not be using __gc for that specific
task.

-- Roberto