Re: scratch/igc: Implications of MPS being asynchronous

[Eli Zaretskii]

> Date: Sun, 12 Jan 2025 16:51:20 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: Stefan Kangas <stefankangas@gmail.com>, emacs-devel@gnu.org, 
> gerd@gnu.org, eller.helmut@gmail.com
> 
> "Eli Zaretskii" <eliz@gnu.org> writes:
> 
> >> +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).

Why do we need to talk about this here?  This document's purpose is to
describe the inner workings of GC, not how Lisp programs can or cannot
control it.  That's for the ELisp manual to describe.  I think having
this here is just a distraction.

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

Can you tell why you think it's important?  And why should it be in
this document?

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

This document's purpose is to describe how GC works in Emacs.  If and
when that changes, the document will have to be updated.  But having
in it stuff that doesn't exist in Emacs will be misleading, IMO.