[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Some experience with the igc branch
From: |
Eli Zaretskii |
Subject: |
Re: Some experience with the igc branch |
Date: |
Sat, 28 Dec 2024 20:02:33 +0200 |
> 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. 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. 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? So now the main thread calls pthread_kill to deliver
the SIGSEGV to the MPS thread, but what will the MPS thread do with
that? how will it know which MPS function to call?
> >> 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.
- Re: Some experience with the igc branch, (continued)
- Re: Some experience with the igc branch, Gerd Möllmann, 2024/12/28
- Re: Some experience with the igc branch, Pip Cet, 2024/12/25
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/25
- Re: Some experience with the igc branch, Pip Cet, 2024/12/26
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/26
- Re: Some experience with the igc branch, Pip Cet, 2024/12/27
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/27
- Re: Some experience with the igc branch, Pip Cet, 2024/12/27
- Re: Some experience with the igc branch,
Eli Zaretskii <=
- Re: Some experience with the igc branch, Pip Cet, 2024/12/29
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/29
- Re: Some experience with the igc branch, Pip Cet, 2024/12/29
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/29
- Re: Some experience with the igc branch, Pip Cet, 2024/12/29
- Re: Some experience with the igc branch, Gerd Möllmann, 2024/12/26
- Re: Some experience with the igc branch, Gerd Möllmann, 2024/12/26
- Re: Some experience with the igc branch, Pip Cet, 2024/12/24
- Re: Some experience with the igc branch, Gerd Möllmann, 2024/12/25
- Re: Some experience with the igc branch, Helmut Eller, 2024/12/25