Re: Garbage collection durint pcall.

[Roberto Ierusalimschy <roberto@...>]

> This may be totally kosher given the right definition. An object is
> dead whenever nobody uses it again, and can be collected at any time
> after that.
> 
> But this definition opens a can of worms for the optimizer. If I do
> a=collectable;.......lot of things....;a=a; the optimizer cannot
> optimize away the a=a stuff, because that object liveness definition
> changes the semantics of a=a, and of all reads of vars in general.

I see the problem the other way around. It is not optimization that
should be restricted; what should be restricted are the assumptions
around finalizers. Of course any optimizer should be able to erase
'a=a' (as long as the assignment itself has no side effects, as it
can have in C++), as it should be able to erase any code that does
not produce side effects.

A finalizer is part of garbage collection, and it should behave as
such. If all a finalizer does is "collect garbage" (free unused memory),
all optimizations are Ok, as long as the code does not access the memory
that might be released. And that is what the optimizer should verify
when doing an optimization. If the optimized code does not need that
piece of memory, it can be relased. That is it.  The "trickiness" comes
from the extended uses of finalizers for all softs of things, not from
the optimizations.

I agree that, in Lua, things are more complex because of its interface
with C. That is why the API has some clear rules around that
subject: Objects in the stack cannot be collected, objects in the
registry cannot be collected, etc.

-- Roberto