Re: scratch/igc: Implications of MPS being asynchronous

[Pip Cet]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> From: Stefan Kangas <stefankangas@gmail.com>
>> Date: Sun, 12 Jan 2025 16:21:06 +0000
>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org, gerd@gnu.org, 
>> eller.helmut@gmail.com
>>
>> Could everyone please take a look at the attached patch (now a bit
>> longer) and see if it matches their understanding?  Thanks!
>
> Thanks, some comments below.

>> +* When does GC happen?
>> +
>> +From the point of view of Lisp code, there are never any guarantees
>> +about when GC happens, neither with the traditional or MPS-based GC.
>> +
>> +However, the old GC has two variables that can be used by Lisp code to
>> +have some amount of control how and when GC happens: =gc-cons-threshold=
>> +and =gc-cons-percentage=.  With IGC, we have given that control over to
>> +the MPS library, which decides when to trigger garbage collection
>> +according to its own heuristics.  This means that the mentioned
>> +variables no longer have an effect.
>
> I don't think we have decided not to allow any GC control from Lisp.
> So maybe it's too early for this text.

I'd suggest:

+However, the old GC has two variables that can be used by Lisp code to
+have some amount of control how and when GC happens: =gc-cons-threshold=
+and =gc-cons-percentage=.  With IGC, the mentioned
+variables no longer have an effect.

(MPS isn't really great when it comes to changing its options at
runtime, so this is a significant task, but certainly not something we
should decide now should never be done).

>> +With the traditional GC, you can also explicitly trigger a full GC, by
>> +calling the function =garbage-collect=.  With IGC, this is no longer the
>> +case, though that function does still perform some necessary internal
>> +cleanups.  The statistics returned by that function are also not
>> +accurate with IGC.
>
> Don't we have igc--colect?

We do, but it's important to emphasize that it's not the equivalent of
garbage-collect.

>> +The story is a bit different in C.  Using the traditional GC, C code
>> +could rely on garbage collection happening only at predictable points in
>> +time.  This means that GC couldn't happen in C code, as long as it
>> +didn't call out to Lisp, or explicitly called GC itself.
>
> It could also happen if the C code called one of the primitives which
> trigger GC.

That's an important point.  We sometimes run Lisp with garbage
collection inhibited.  Those cases are too rare and special to document
them as exceptions here, IMHO.  Drop the last sentence, I'd suggest:
if we make it accurate, it's too long to be useful.

>> +With MPS, the GC "might be scanning, moving, or collecting, at any point
>> +in time (potentially, between any pair of instructions)" (Memory Pool
>> +System Guide, ch. 2).  For this reason, we try to write C code without
>> +making any non-GC assumptions.
>
> We should be describing what happens with the part of MPS we actually
> use in Emacs, the way we use it.

I disagree.  We should not document implementation details of MPS unless
we decide to explicitly rely on them.  That MPS currently does not
create extra threads for GC, by itself, is one of those.

Pip