Re: Opportunistic GC

[Pip Cet]

On Mon, Mar 8, 2021 at 2:45 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Pip Cet <pipcet@gmail.com>
> > Date: Mon, 8 Mar 2021 07:20:28 +0000
> > Cc: emacs-devel@gnu.org
> >
> > My implementation proposal would be to pipe(), fork(), run GC, then
> > send through the pipe the Lisp_Objects which can be collected by the
> > original Emacs.
>
> What happens when, on a 8GB machine, we have an Emacs session with a
> 5GB memory footprint, and you fork and start marking (which triggers
> copy-on-write)?

That is, indeed, one of the cases in which we have to use the
synchronous GC or suffer the consequences.

Let me be clear about that: yes, it would use (up to) 10 GB of memory,
if you really have 5 GB of Lisp data.

> Also, I quite frequently need to run Emacs on a system where I'm
> forbidden to run more than 2 processes simultaneously ("make -j3"
> aborts with an error message), and you propose to take those two
> processes with 2 copies of Emacs?

That is, indeed, one of the cases in which we have to use synchronous GC.

> IOW, I don't believe this scales well enough.

I believe it has applications, including my own personal use of Emacs.
I don't believe it's universally better than synchronous GC.

> > Eli, would this qualify as a "small" GC change, and thus be vetoed?
> I don't yet see how it is a good idea to begin with.  I'm probably
> missing something.

Once in a while, every few days or so, GC happens at an inconvenient
time to me. I'd like to interrupt it, but I can't. I'd like for Emacs
not to become unresponsive while it's mark-and-sweeping, but it is.
Sometimes, I end up killing Emacs rather than waiting for GC to
complete.

Pip