Re: scratch/igc: Implications of MPS being asynchronous

[Gerd Möllmann]

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.

> This makes it clear what it means not to "allow" C code to make "no GC
> here" assumptions.  But I don't understand what it means that it is not
> "required" to make such assumptions.  Could someone clarify that part
> please?
>
> I would suggest documenting this somehow.  The attached patch is the
> best proposal I could come up with based on my understanding so far.
> Does what I wrote there make sense?  Should it be expanded somehow?
> (If someone else wants to write something better, please go ahead.)
>
> We also have a couple places where we currently call
> `inhibit_garbage_collection`.  Do we need to do anything about them?

No, it's a nop with igc. One could compile it out, maybe, but I leave
it to future generations to save these nanoseconds :-).

> I assume that it's not a good idea (due to performance, and maybe
> other things also) to simply run `mps_arena_park` and `arena_release`
> around these points?

Right, not a good idea at all.

Patch LGTM. Thanks!