lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]




On Sat, Jun 1, 2019 at 2:13 PM Andrew Gierth <andrew@tao11.riddles.org.uk> wrote:
>>>>> "Francisco" == Francisco Olarte <folarte@peoplecall.com> writes:

 >> A general observation: An optimizing implementation of Lua could do
 >> variable liveness analysis and reuse stack slots, resulting in the
 >> following:

 >> function f(x)
 >>   print(x)
 >>   local y = g() -- this overwrites x, making it collectable
 >>   print(y)
 >> end

 Francisco> I think this would be a faulty optimizer. To be exact, I
 Francisco> think doing this and allowing the value to be collected
 Francisco> would be an optimizer error. I have not tried to understand
 Francisco> the spec in detail, but, in a language with finalizers which
 Francisco> can be observed, this changes the semantics of the program.

There's a specific idiom that this kind of optimization would break,
which is when one fetches a key or value from a weak table into a local
variable purely to ensure it does not get collected during some process.
In this case the local variable might never be referenced at all after
assigning it.

--
Andrew.

This is often called RAII ("resource acquisition is initialization" but the actual practice of it doesn't quite fit that exact description anymore).

The solution is to assert that <toclose> variables are always considered live. It is, after all, an explicit declaration that the end of the variable's lifetime is precisely the same as the end of the lexical scope. And this would also be one of the more common reasons to use a <toclose> variable in the first place, so it's a win-win.

/s/ Adam