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:
>
>>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>>> Cc: stefankangas@gmail.com,  pipcet@protonmail.com,  ofv@wanadoo.es,
>>>   emacs-devel@gnu.org,  eller.helmut@gmail.com,  acorallo@gnu.org
>>> Date: Fri, 27 Dec 2024 19:21:30 +0100
>>>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>> >   - 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 also thought MPS GC runs concurrently in
>>> > its own thread.
>>>
>>> What Pip said was very easy to misunderstand, to say the least :-). No,
>>> MPS is concurrent, period. There are situations in which MPS can, in
>>> addition, use the main thread. And it's still concurrent, period.
>>
>> How can you see which thread runs MPS?  Where should I put a
>> breakpoint to see that (IOW, what are the entry points into MPS GC
>> code)?

I'd suggest ArenaEnter or MessagePost.

>> If I run Emacs with a breakpoint in process_one_message (after
>> enabling garbage-collection-messages), all I ever see is GC triggered
>> by igc_on_idle, which AFAIU is only one of the way GC can be
>> triggered.  Where are the entry points for the other GC triggers?  I'm
>> asking because I'd like to run Emacs like that and see which thread(s)
>> run GC.
>
> I wonder if your interpretation is right here. AFAIR,
> process_one_message is always called from igc_on_idle. IOW, we handle

There's a second call path when we create finalizable objects
(maybe_process_messages).

> messages from MPS only when Emacs thinks it's idle, and that is always
> in the main thread.

My understanding is, also, that process_one_message doesn't trigger GC,
it handles messages produced by GCs triggered in other places.

> The messages are produced and put into the MPS message queue in the MPS
> thread, usually. Or maybe, I don't know that for a fact, also in the
> main thread, when allocation points run out of memory, or when we do an
> mps_arena_step. The arena step thing is only done if igc-step-interval
> is non-zero, which is not the default. (I'm personally using 0.05 = 50
> ms, BTW.)

It's usually the main thread here.

> How to get hold of the MPS thread I don't know. I just see one thread
> more when using igc than with the old GC. Maybe one could sett a

My understanding is that's the exception handling thread, which only
ever runs when another thread hits a memory barrier and is suspended
waiting for its resolution; as with my patch, this is about separate
stacks (and signal handling contexts), not about parallelism.

So it seems we're miscommunicating about these "MPS threads".  What are
they?  Where are they created?  What do they do?

If we can't answer that, it'll be harder to decide what to do about
signal handlers calling into MPS.

Pip