Re: Some experience with the igc branch

[Gerd Möllmann]

Pip Cet <pipcet@protonmail.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>> We're coming from the problem that MPS uses signals for memory barriers.
>> On platforms != macOS. And I am proposing a solution for that.
>
> I don't think that's the problem.  The problem is that signals can
> interrupt MPS, on all platforms.  We can't have MPS-signal-MPS stacks,
> ever.  The best way to ensure that is to keep signals on one stack, and
> MPS on another stack.  MacOS already does that for their SIGSEGV
> equivalent, but we need to do it for all entry points into MPS.
>
> If they don't have separate stacks, and we interrupt MPS, the signal
> handler cannot look at any MPS-modifiable memory (including roots, which
> may be in an inconsistent state mid-GC), ever.  This includes the
> specpdl.  We can't write to MPS-known memory, ever.  This includes any
> area we might want to copy the backtrace or specpdl to.

And I don't think that's right :-). It's completely right that in the
SIGPROF handler everything can be inconsistent. That's true both for MPS
and Emacs. For example, the bindings stack (specpdl) may be inconsistent
when SIGPROF arrives. Literally everything we do in the SIGPROF runs the
risk of encountering inconsistencies.

I think that's already true for the old GC. There is nothing
guaranteeing that the contents of the binding stack is consistent, for
example. But we get away with it well enough that the profiler is
useful.

With MPS, from my POV, the situation is pretty similar. Try to get away
with it by not triggering MPS while in a state that we must assume is
inconsistent.

>> The SIGPROF handler does two things: (1) get the current backtrace,
>> which does not trip on memory barriers, and
>
> Even if the specpdl were an ambiguous root, we'd be making very
> permanent and far-reaching assumptions about how MPS handles such roots
> if we assumed that we could even look at such roots during GC.  This
> goes doubly for assuming that we can extract references to
> ambiguously-rooted objects and put them into other areas of MPS-visible
> memory.  Even if this worked perfectly with current MPS on all
> platforms, it would still be unreasonable for us to rely on such
> implementation details.
>
> We can't do (1).

I disagree, abviously :-)

For me, it's not about a theoretical or even practical solution that
somehow ensures a consistent state in MPS, or some future changes in MPS
or something. It's about getting away with what we do in the profiler
_now_, as we do with the old GC. which is already seeing potentially
inconsistent state in Emacs' memory.

I think the _now_ is also important. From my POV, we could discuss
better solutions later.