Re: Opportunistic GC

[Pip Cet]

On Tue, Mar 9, 2021 at 1:01 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Pip Cet <pipcet@gmail.com>
> > Date: Mon, 8 Mar 2021 14:57:06 +0000
> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> >
> > > 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.
>
> How do we know if/when we are in that case?  Because if we err, we
> have a meeting with the OOM killer and a swift death.

Yes, but there's a good chance we would have had that anyway, since
it's "only" a factor of two, at most.

I see similarities to how we decide how many processes to use for
native compilation. The current rule in that case is "half the
system's reported number of CPUs", however that is determined.

I don't see why we can't do the same thing for memory: if there's a
chance the GC process plus the current Emacs process exceed half of
the lowest of
1. system memory
2. ulimit memory
3. a sensible upper limit,

we use synchronous GC by default. Of course this should be
customizable because users know best.

If you're arguing that there is a strong case that synchronous GC
should remain the default, I'm inclined to agree, because we haven't
even tried the other way or gained any experience with it so far. But
that does not mean it has no application whatsoever. I would gladly
trade doubled memory consumption for reliable, reliably interruptible,
zero-latency GC, particularly if it means never having to mask out
mark bits before inspecting objects after a crash again :-)

> > > 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.
>
> Again, how do we know we are in that case?

I assume you don't have a reliable getrlimit that lets you know?

Pip