Re: scratch/igc: Implications of MPS being asynchronous

[Pip Cet]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> In Bug#75322, Pip Cet writes:
>>
>>> The MPS-based GC in scratch/igc does not allow or require application
>>> C code to make "no GC here" assumptions.
>>
>> This is stated quite unambiguously also in the MPS guide:
>>
>>      "The MPS is asynchronous: this means that it might be scanning,
>>      moving, or collecting, at any point in time (potentially, between
>>      any pair of instructions in your program)."  (Chapter 2)
>
> Among the things that made me think it's concurrent. Still a bit grumpy.

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.

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.

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

Pip