Re: Garbage collection durint pcall.

[Francisco Olarte <folarte@...>]

On Mon, Jun 3, 2019 at 5:38 PM Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>
> > I do not see the point of this "make things collectable ASAP",
> > "agressively reuse everything", [...]
> Agressively reusing registers in a CPU is one of the most important
> optimizations in a compiler.

This has nothing to do with CPU registers, reusing them is easy when
you can load them again from RAM, or when they are just used for
pointers or counters whose semantics are extremely easy to follow. I
have no problem with reusing them. Lua objects, slots, whatever, are
not CPU registers. Given how lua is defined, in ANSI C, you do not
even need CPU registers to make it run, you can use a stack machine,
or a CPU with direct meory addressing for all operands, as long as you
have a C compiler. What I mean is that they are reusing lua-level
stuff, transforming things like

local a=anything
do whatever with a
do more things
local o=otherthing
do whatever with o

to reuse a to store o. Easy to do in any language where local is just
used as a place to store a ref/marker/whatever like say, C, or
assembler, not so easy the moment you make value collection a
significant event, but, again, whatever. I've already decide to switch
to toclose if I go to lua 5.4 and hope (and test if I can) my
asumptions hold correct in 5.3.

> The fact that an object becomes
> unreacheable when the register is used for another reference is only a
> side effect.

A CPU register is loaded from ram, (normally, you can have it come
back from a function), objects do not become unreachable because you
zap them, you still have the copy in ram. Unreachability is at a
higher level.

> The same is true for other optimizations (e.g., dead-code
> elimination). They are not trying to make things collectable ASAP, that
> is only a side effect.

I assume they are not doing things collectable for the fun of it, it
doesn't optimize a thing. But they are (trying to? ) not keeping
things uncollectable. Seeing the 5.4 manual still has the same
definition, I'll keep assuming it will not collect my data, but, after
your last message with the tentaive definition, I do not have high
hopes of it being like this for too long. I'll just assume finalizers
are tainted and avoid them, as I said, I've coded enough to be able to
do it in other ways, and it's easier for me to assume "finalizers can
run anytime" ( not anytime, just not after end of scope, but it makes
it complex if I have to check every interaction, I use lua becuase it
makes things simpler ) than to try to learn some complex rules of "if
they could have been collected if they were non existent". It's easy,
even with C mixed in, it will raise complexity but not that much, and
I have a fixed complexity limit on just doing everything in the host
(which this years is typically C++ where I use lua, and I have simpler
scoping rules there ) ( I always use lua hosted ( or is it embeded?  )
).

Francisco Olarte.