Re: scratch/igc: Implications of MPS being asynchronous

[Pip Cet]

"Stefan Kangas" <stefankangas@gmail.com> writes:

> 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?

My guess is these are the two main reasons:

1. MPS needs to decide how much GC work to do.  That decision is never
easy, even in the single-thread case, but it's harder if we're called
from another thread and we don't know, for example, how much the main
thread has been allocating.  MPS uses POSIX locking and POSIX locks have
no good way of communicating lock contention, so MPS cannot take that
into account.

2. MPS interrupts other threads.  Considerable overhead, and an
interrupted thread may use significantly more stack space than one which
is at an allocation point.

> 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.

To me, concurrent GC means that correctnes is established by atomic
operations or locking.  In the case of MPS, it's usually locking, and
locking isn't free.

> Is that view too naive?

I don't know.  My intuition is that concurrent GC will be worth it if
it's fine-tuned, but there will always be weird corner cases where it's
not.  Maybe that's wrong, and it's almost always worth it.

>> 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.

You're right for the no-GC case.  Rare-GC assumptions are a design
choice we should avoid, no-GC assumptions violate the clearly-stated
rules for using MPS, so we can't make them.

>> (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.)

Not entirely sure, but it's probably easiest to keep parking the arena
there.

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

Yes.

Pip