Re: Some experience with the igc branch

[Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>]

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.

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

>> Doing this from another thread raises the problem I describe above: we
>> need the Lisp thread(s) stopped, because you cannot examine the data
>> of the Lisp machine while the machine is running.  And if we stop the
>> Lisp threads, why do we need the other thread at all?

Because MPS can continue and reach an MPS-consistent state only if it
has its own stack.  In practice, this means an extra thread.

Or we re-raise signals (scratch/igc right now; this will delay signals
unpredictably), or we block them for the allocation fast path
(significant slowdown on some systems) *and* in the SIGSEGV handler
(which we'd need to "steal" from MPS, calling it from our real signal
handler by extracting sa_sigaction and calling that pointer.  Recipe for
disaster).

I'm still convinced the extra thread is the least painful option,
followed by what we have now.

Pip