Re: Some experience with the igc branch

[Pip Cet]

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

It's what the rest of Emacs should assume, IMHO, but it's certainly not
true that GC "runs in its own thread": it uses whichever thread is
current at the time we enter MPS.

> At least on Windows, I clearly see new threads starting when MPS
> starts GC.

You mean MPS calls CreateThread?  GC creates no threads on GNU/Linux.

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

Sounds like I misunderstood, then.

If we all agree that Emacs shouldn't assume GC non-concurrency,
triggering GC eagerly from another thread is a useful thing we should
test (after making dflt_pad poison memory, ideally).

Pip