Re: Question about 4.1 optimization

[Roberto Ierusalimschy <roberto@...>]

> the new handling of L->top in luaV_execute is a clever idea.

We are going through a big change in luaV_execute. So, many things you
saw there will change (but this handling of L->top will not :-).

We are building a new set of opcodes, so that luaV_execute will not
be a stack machine. It will fix L->top at entrance, and then use all
entries between base and L->top as `registers'. All opcodes will have
explicit operands. That will save lots of "getlocal" and "setlocal"
opcodes, as operators will operate directly on the local. As getlocal
is one of the most frequent opcodes, we expect that change to bring
some performance improvment.

> If the L->top returned by the call is lower than maxstacksize
> then there will be some arbitrary objects on the stack between
> top and L->top which, when not overwritten by some code within
> the function, will not be garbage collected.

Yes, that is true. That is, they will hang around for a while, until
they are overwritten, or the function ends, or a garbage collection
happens inside a function called by this one (when a function calls
another one, L->top is "corrected"). Specifically, if the function
calls "collectgarbage", all those arbitrary objects will be proper
collected.

> The other case looks suspicious too.  If the functions returns
> more results than fit into maxstacksize there will be valid
> objects above L->top (top > L->top!).

An "open" function call (that is, a call that returns an unknown number
of results) will still be tricky in this new implementation. Such
instructions are always immediately followed by an "appropriate"
instruction that "uses" all those values (a return, another call,
or a setlist).


> PS: Is this code in lgc.c:markstacks debug code?  Looks strange ;)
> ----
>     lim = (L1->stack_last - L1->ci->base > MAXSTACK) ? L1->ci->base+MAXSTACK
>                                                      : L1->stack_last;

This is the trickyest part :-(  When "a" calls "b", L->top may be set
lower than it was in "a". So, some objects between the new top and
a->base+a->maxstack could be collected. Later, back in "a", the garbage
collector may try to mark them (as they are live, as you pointed out
before). But now they are garbage (they were collected)! The above code
creates a "safer" zone, so that any object which now are garbage but
may look "alive" later is set to nil. (Not very clear the explanation,
is it?)

-- Roberto