scratch/igc: Implications of MPS being asynchronous

[Stefan Kangas]

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)

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

Thanks!

0001-admin-igc.org-Document-that-MPS-is-asynchronous.patch
Description: Text Data