Re: scratch/igc: Implications of MPS being asynchronous

[Stefan Kangas]

Pip Cet <pipcet@protonmail.com> writes:

> I still think MPS is bring-your-own-thread concurrent, FWIW.  All you
> have to do is to create an extra thread and repeatedly call into MPS,
> and you get concurrent GC.
>
> Not necessarily better for performance (particularly not in our case:
> too many roots, none of them protected.  Also, no signal handlers while
> the main thread is suspended), but it works.

Could you explain why performance would not be better?

Concurrent GC to me means that the mutator thread only ever does atomic
operations that are safe to intermingle with atomic operations done by
the collector thread, and vice versa.  Once they run in different
threads, performance is just better because they can run on different
cores.

Is that view too naive?  I understand why blocking signal handling could
be a problem, but other than that I don't think I follow.

> And keeping that option open is why I thought it so important that we
> don't start making rare-GC (or, worse, no-GC) assumptions.

Hmm.  I thought that the reason was fundamentally that a GC could strike
at any time, as documented in the MPS manual?  IOW, that this is
non-optional, and not a design choice on our end.

> (IMHO, the only place that should ever park the arena is Figc_info.  If
> there's an appreciable performance impact from replacing realloc by
> malloc-then-free for MPS roots, those roots are too large.)

(We also need it in make_arena and Fdump_emacs_portable, I think.)

Does that mean that you think we should get rid of IGC_WITH_PARKED?