Re: Concurrent GC via `fork` (was: Opportunistic GC)

[Pip Cet <pipcet@gmail.com>]

On Mon, Mar 8, 2021 at 4:03 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> > 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?
>
> Sounds like a good idea.

Thanks.

Sorry for derailing your thread, I should have chosen a new subject.

> A concurrent GC which relies on `fork` to take the snapshot.
> I don't think we'll be able to always use it, so the synchronous code
> path will have to stay,

Absolutely.

And I do want to mention weak hash tables: they're a problem, because
they can resurrect unreachable objects. Worse, while normal
weak-key-strong-value hash tables only resurrect objects when you
maphash, weak-value hash tables can do so for gethash as well, so that
code path would become more expensive and more difficult to translate
into native code.

> but I think it's definitely worth working on it.

I've got it working for conses, I think (as a proof of concept,
synchronously, with an extra waitpid()).

> It will probably require moving the markbits out of the objects in order
> to work well (which would probably be beneficial in the synchronous GC
> case as well), but other than that I'd expect it should be possible to
> get pretty good performance out of it in the "normal" case:

The normal case, for me, is Emacs freeing a lot of memory in a GC
cycle, and keeping only a relatively small working set. That should
work well with the way markbits are written only for objects that are
to be kept.

> - most pages should stay shared between the two processes (because the
>   GC process should basically only modify its stack and its markbit
>   pages, and the parent process should hopefully not have enough time to
>   modify a large fraction of its working set).
> - the "normal" case I envision is one where there's a fair bit of extra
>   RAM left in the system and a few CPU cores waiting to help Emacs.

Indeed.

Apart from hating threads and loving processes, I love nice levels,
and I think this would be a good use case for them. For example, I
hear there's a new CPU out there that has two separate sets of cores
for "efficiency" and "performance", and it would be great if Emacs ran
an "efficiency" garbage collection in the background rather than a
"performance" garbage collection synchronously.

> > Eli, would this qualify as a "small" GC change, and thus be vetoed?
>
> I like the idea, but its inclusion can't be discussed without
> a proof-of-concept patch.

I think that's the sensible approach, yes. I certainly wasn't hoping
to hear anything _positive_ before submitting a patch.

Pip