Re: Some experience with the igc branch

[Pip Cet]

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

>> Date: Fri, 27 Dec 2024 16:42:48 +0000
>> From: Pip Cet <pipcet@protonmail.com>
>> Cc: gerd.moellmann@gmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, 
>> eller.helmut@gmail.com, acorallo@gnu.org
>>
>> "Eli Zaretskii" <eliz@gnu.org> writes:
>>
>> >> All redirected MPS calls wait synchronously for the allocation thread to
>> >> respond.
>> >>
>> >> This includes the MPS SIGSEGV handler, which calls into MPS, so it must
>> >> be directed to another thread.
>> >
>> > MPS SIGSEGV handler is invoked when the Lisp machine touches objects
>> > which were relocated by MPS, right?
>> > What exactly does the allocation thread do when that happens?
>>
>> Attempt to trigger another fault at the same address, which calls into
>> MPS, which eventually does whatever is necessary to advance to a state
>> where there is no longer a memory barrier.  Of course we could call the
>> MPS signal handler directly from the allocation thread rather than
>> triggering another fault.  (MPS allows for the possibility that the
>> memory barrier is no longer in place by the time the arena lock has been
>> acquired, and it has to, for multi-threaded operation.)
>>
>> What precisely MPS does is an implementation detail, and may be
>> complicated (the instruction emulation code which causes so much trouble
>> for weak objects, for example).
>>
>> I also think it's an implementation detail what MPS uses memory barriers
>> for: I don't think the current code uses superfluous memory barriers to
>> gather statistics, for example, but we certainly cannot assume that will
>> never happen.
>
> I think you lost me.  Let me try to explain what I was asking about.
>
> MPS SIGSEGV is triggered when the main thread touches memory that was
> relocated by MPS.

(well, the memory hasn't been relocated, it just contains invalid
pointers).

> With the current way we interface with MPS, where
> the main thread calls MPS directly, MPS sets up SIGSEGV to invoke its
> (MPS's) own handler, which then handles the memory access.

It removes the barrier and returns, making the main thread try again.

> By
> contrast, under your proposal, MPS should be called from a separate
> thread.  However, the way we currently process signals, the signals
> are delivered to the main thread.  So we should install our own
> SIGSEGV handler which will run in the context of the main thread, and
> should somehow redirect the handling of this SIGSEGV to the MPS
> thread, right?

Correct.

> So now the main thread calls pthread_kill to deliver
> the SIGSEGV to the MPS thread,

No, that wouldn't work.  We need the signal handler to have access to
the siginfo_t data, and pthread_kill provides no way to include that
information.

Instead, we call the SIGSEGV handler directly on the other thread,
passing in the same siginfo structure.

(My original code simply accessed a byte at the fault address; however,
reading the byte isn't sufficient, and writing it risks exposing
inadmissible intermediate states to other threads, so now we call the
sa_sigaction function directly).

> but what will the MPS thread do with that?

Call the MPS SIGSEGV handler, which knows what to do based (currently)
only on the address.

> how will it know which MPS function to call?

The MPS SIGSEGV handler is obtained by calling sigaction.

>> >> 3. we don't allocate memory
>> >
>> > Why can't GC happen when we don't allocate memory?
>> >
>> >> 4. we don't trigger memory barriers
>> >
>> > Same question here.
>>
>> I meant all four conditions are necessary, not that any one of thew
>> mould be sufficient.
>>
>> GC can happen if another thread triggers a memory barrier OR another
>> thread allocates OR we hit a memory barrier OR we allocate.  The
>> question is whether it is ever useful to assume that GC can happen ONLY
>> in these four cases.
>
> GC can also happen when Emacs is idle, and at that time there's no
> allocations.

If you want to spell it out, sure, but there's no way for the main
thread to become idle without potentially allocating memory, so this
fifth condition is redundant.

Pip