[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: LuaJIT and keeping objects alive
- From: Roberto Ierusalimschy <roberto@...>
- Date: Wed, 25 Nov 2009 17:17:44 -0200
> 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)
> function bar(U)
> ...lots of processing that might force a garbage-collection...
> ...nowhere here do we do anything with U...
> 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