Re: Some experience with the igc branch

[Pip Cet]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  pipcet@protonmail.com,  ofv@wanadoo.es,
>>   emacs-devel@gnu.org,  eller.helmut@gmail.com,  acorallo@gnu.org
>> Date: Fri, 27 Dec 2024 14:56:06 +0100
>>
>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>
>> > I've reached the point where I don't know what else to explain. Could
>> > always be improved, of course, and so on. Please find attached, with
>> > request for feedback.
>>
>> Ahem, just remembered that I had already an admin/igc.org in the branch,
>> so I've now replaced that with what I've written.
>
> Thanks.  Some questions about that file:
>
>   In contrast, the new igc collector, using MPS, is
>
>   - Concurrent.  The GC runs in its own thread.  There are no explicit
>     calls to start GC, and Emacs doesn't have to wait for the GC to
>     complete.
>
> Pip says this is not true?

I'm a bit confused.  Right now, on scratch/igc, on GNU/Linux, for Emacs
in batch mode, it isn't technically true.  This causes the signal
handler issue, which we're trying to solve.  One of my approaches is to
MAKE this statement true, by using a separate thread for allocation
(which triggers GC) and access faults (which call into MPS, which counts
as triggering GC in my book).

> I also thought MPS GC runs concurrently in its own thread.

That's what you should think: GC can strike at any time.  If your code
assumes it can't, it's broken.

As far as everybody but igc.c is concerned, it's safer to assume that GC
runs on a separate thread.  igc.c currently detects (with false
positives) the one very special situation in which it is UNSAFE to
assume that, and acts accordingly.  The allocation thread patches would
make it so the assumption is actually true.

Pip