Re: Next steps for igc feature branch

[Pip Cet]

"Helmut Eller" <eller.helmut@gmail.com> writes:

> On Wed, Apr 30 2025, Pip Cet wrote:
>
>> "Helmut Eller" <eller.helmut@gmail.com> writes:
>>
>>> The difference is that hardware protection bits are the same for all
>>> threads.  By contrast, a collector thread can ignore software barriers
>>> while mutator threads normally check/update the memory barriers.
>>
>> Ah, thanks, that makes sense!  I think that's solvable using double
>> mappings
>
> Hmm.. that's a clever idea!

I fear it may not be obvious how this discussion relates to Emacs, but
it does, so here's my attempt at a summary:

We're looking at MPS limitations which might cause trouble for Emacs,
particularly if either Emacs itself or the way we call into MPS becomes
more multi-threaded.

I performed some experiments, and my current opinion is that MPS can be
improved (without a fundamental redesign) to reduce the impact of one such
limitation.

This doesn't solve all problems hardware memory barriers have (in
particular, they still use page granularity), but it does mean, IMHO, it
makes sense to continue working on MPS-based GC for Emacs.

If the lack of parallelism, as I expect and hope, becomes a major issue
(meaning that catastrophic bugs no longer are frequent enough to be the
main concern), we can go back to these experiments and improve MPS in
these ways.

So the idea may be clever, and there is code that doesn't crash
immediately, but it's really something we should remember for the
future, if and when we turn out to need it, and we'd need to fix at
least two things:

1. forking a process which has double-mapped memory ends up sharing the
child and parent processes' view of the memory.  A fix is possible, but
would be expensive and complicated.  (Not a problem with pkeys, though).

2. _mps_fix2 isn't atomic (it doesn't use compare-and-exchange), and
there's this comment in traceScanSegRes:

 * @@@@ During scanning, the segment should be write-shielded to prevent
 * any other threads from updating it while fix is being applied to it
 * (because fix is not atomic).  At the moment, we don't bother, because
 * we know that all threads are suspended.  */

I hope that comment is obsolete, because I can't make sense of it :-)

Anyway, something to keep in mind for the future, but I'd also like to
look at the possibility of interrupting MPS traces when input becomes
available.

Pip