Re: Opportunistic GC

[Pip Cet]

On Mon, Mar 8, 2021 at 2:01 PM Andrea Corallo <akrl@sdf.org> wrote:
> Pip Cet <pipcet@gmail.com> writes:
>
> > On Mon, Mar 8, 2021 at 3:37 AM Stefan Monnier <monnier@iro.umontreal.ca> 
> > wrote:
> >> I've been running with the code below recently to try and see if
> >> opportunistic GC can be worth the trouble.
> >
> > Just a random idea: What if we exploit the fact most people have more
> > than one CPU core these days, garbage-collect in a separate fork()ed
> > process, then do only the sweeping in the main process?
>
> It's an interesting concept, I thought about something similar in the
> past but, I've two questions:
>
> Are we really sure that a non trivial process can long survive
> or work as expected after being forked?

I believe that, on all systems where bash works, we can expect fork()
to behave. We do need to block signals, obviously, and must not do any
real I/O in the subprocess (in particular, we must not
unblock_input(), which I confess I did until just now).

> Do we have (an efficient) fork on all supported systems?

I'm not sure. I do know some systems prefer using spawn() to fork() +
exec(), and I always suspected the main reason for that is because
they do not have an efficient fork().

I do think that there should always be a runtime option to get the
conventional synchronous GC, as that is bound to remain the faster
option.

As Eli points out, there are at least two significant use cases in
which we have to use synchronous GC: low memory machines with large
workloads, and limits on the number of processes we can launch. I
believe single-thread machines are also likely not to benefit from it.

But note that we already do launch quite a few asynchronous Emacs
instances, on the native-comp branch. This would be just one, a
short-lived one at that.

Pip