lua-users home
lua-l archive

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

Hi,

the new handling of L->top in luaV_execute is a clever idea.
Together with the luaH_nexti in the for-loop the benchmark
freaks will be happy ;-)

But one thing I'm not sure about:

      case OP_CALL: {
        int nres = GETARG_B(i);
        if (nres == MULT_RET) nres = LUA_MULTRET;
        L->top = top;
        luaD_call(L, base+GETARG_A(i), nres);
        top = L->top;
        L->top = base+tf->maxstacksize;
        break;
      }

Is the last line (L->top = base+...) really correct for MULTRET
functions?

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.

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!).  I tried to see what
opcodes will normally follow OP_CALL(MULT_RET) and it seems
all of them will not generate a GC check unless L->top has
been corrected.  If this is really the case and intended I
would suggest a comment above the mentioned line. (Something
like /* may leave live objects above L->top */)

But maybe I've just missed something important.  In that case
I apologize for the noise.

Ciao, ET.

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;
    for (; o<=lim; o++) setnilvalue(o);
----