Re: MPS: Bytecode stack

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> 6 maj 2024 kl. 14.47 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:
>
>> It would be easiest if you'd look at scan_bc in igc.c on the branch
>
> I did, which is why I wondered whether I had understood the problem correctly. Maybe we can help each other:
>
>>    /* FIXME: AFAIU the current top frame starts at bc->fp->next_stack
>
> Does it? Look at the ASCII art in bytecode.c. During bytecode
> execution, fp->next_stack is the lowest completely unused entry of the
> bytecode stack, but that refers to the engine register `fp` which is
> almost but not entirely in sync with `bc->fp`. There are gaps when
> there is live data on the stack beyond bc->fp->next_stack, such as
> during frame setup:
>
>  514   Lisp_Object *frame_base = bc->fp->next_stack;
>  515   struct bc_frame *fp = (struct bc_frame *)(frame_base + max_stack);
>  516 
>  517   if ((char *)fp->next_stack > bc->stack_end)
>  518     error ("Bytecode stack overflow");
>  519 
>  520   /* Save the function object so that the bytecode and vector are
>  521      held from removal by the GC. */
>  522   fp->fun = fun;
>  523   /* Save previous stack pointer and pc in the new frame.  If we came
>  524      directly from outside, these will be NULL.  */
>  525   fp->saved_top = top;
>  526   fp->saved_pc = pc;
>  527   fp->saved_fp = bc->fp;
>  528   bc->fp = fp;
>
> which is why I was concerned about whether there might be a race
> somewhere. Note, however, that in this particular window we don't
> stash anything to the stack beyond bc->fp->next_stack that isn't
> already accessible via ambig refs elsewhere (`fun` in particular).
>
> There may be similar gaps when we pop stack frames: return from a
> function and in the catch and condition-case handling, but it would be
> easier if I knew what I was looking for.

Ok, let me try to explain. Thanks for looking into this!

I made the bc stack(s) ambig roots (conservativly scanned, like with
mark_memory). For the root address range I use the stack's start and
end. Since that is quite large (512K?), I though it a good idea to scan
less. So scan_bc tries to figure out an 'end' address that is smaller
the whole stack's end. That's all it is about. How to find a realistic,
scan end.