Re: MPS: Bytecode stack

["Mattias Engdegård" <mattias.engdegard@gmail.com>]

6 maj 2024 kl. 11.58 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:

> I think I fixed, or better said worked around, something important today
> in scan_bc which can lead to objects being "lost". Might be interesting
> to see if some errors magically disappear.

I'm not sure what you are trying to fix. Dodging a data race?

To see if I understood what your problem is, and how MPS works, consider the thread state

Lisp_Object *a;
int top;

where `a` is a heap-allocated array of some size, but only indices [0..top] are actually used so the GC doesn't need to look at the rest. The mutator thread does:

1  x = a[top];
2  top = top - 1;

What does the GC thread see? Even if it reads a (signal-atomic) snapshot of the mutator's register and stack, does this atomicity extend to `top` which isn't even a Lisp_Object? Is the mutator suspended during this scan?

Furthermore, the compiler is allowed to hoist the store in line 2 past the load in line 1. If that's the only problem, it may just be a matter of adding a compiler barrier (acquire).