Re: MPS: Bytecode stack

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

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> 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.

Or, wait a moment... I'm wondering about what happens when the client
continues to exec byte code while we are scanning... The root is not
like objects in MPS memory to which we get granted exclusive access. Or
so I think ATM. But roots can have a barrier applied to them, I think.
MPS_RM_PROT. I have to read a bit.

(BTW, funny I think: Emacs/master froze while having Emacs/igc in LLDB,
and Emacs/igc was still functioning well :-))