Re: Some experience with the igc branch

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 27 Dec 2024 15:01:11 +0000
>> From: Pip Cet <pipcet@protonmail.com>
>> Cc: Stefan Kangas <stefankangas@gmail.com>, Eli Zaretskii <eliz@gnu.org>, 
>> ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org
>> 
>> > - 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.
>> 
>> I don't think that's true right now (it is what I want for Christmas,
>> though).  On GNU/Linux, the GC usually runs on the main thread.
>
> Isn't it both, actually?  That is, MPS could be triggered both
> synchronously and on a separate thread?  That's what I thought.
>
> At least on Windows, I clearly see new threads starting when MPS
> starts GC.
>
>> On
>> macOS, the GC can run on the main thread (allocation) or on the SIGSEGV
>> handler thread (memory barriers); in both cases, the main thread has to
>> wait for it to complete.
>> 
>> I'm not sure it's ever useful to make the assumption that GC isn't
>> concurrent:  it is very hard to do so, but it is possible.
>> 
>> Maybe Eli knows more; I posted a patch to force concurrent GC for
>> debugging a while ago, and Eli told me not to because it would produce
>> false positives.  I'm not so sure about the "false" part now.
>
> I just conveyed what a comment in igc.c says (or used to say back in
> May).

MPS is concurrent.

One can tell MPS that one has a certain amount of time to spare, so it
can do work then, which I think runs in the main thread. I do that when
Emacs thinks it's idle.

There is also the case when an allocation point runs out of memory, but
I don't want to open that box at the moment. I personally believe that
this is too special for igc.org. But others may think differently of
course.