Re: scratch/igc: Implications of MPS being asynchronous

[Eli Zaretskii]

> Date: Sun, 12 Jan 2025 14:50:35 +0000
> Cc: stefankangas@gmail.com, emacs-devel@gnu.org, gerd@gnu.org
> From:  Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> "Eli Zaretskii" <eliz@gnu.org> writes:
> 
> > What I'm saying is that it's okay to have a rule like: "write your
> > code as if GC could happen at any time".  But saying that GC actually
> > _can_ happen at any time is too far-fetched since it's factually
> > false.
> 
> No one said "can"!  The quote used "might", not even "may", and included
> an extra "potentially", so you're objecting to a statement that no one
> actually suggested.
> 
> Here's the statement, for reference:
> 
>      "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)
> 
> Anyway, a separate background MPS collection thread isn't far-fetched,
> and makes the hypothetical "GC actually can happen at any time"
> statement true.
> 
> I'm not using one right now, but this discussion convinced me that we
> should do so, and fix any and all bugs discovered that way, even if
> there is a convoluted defense for why they may be impossible to trigger
> without the extra thread.
> 
> > Because GC can be entered via a very small number of calls,
> 
> ... and all accesses to memory behind a barrier ...
> 
> > and it is not hard to define the conditions under which it can or
> > cannot be entered.
> 
> Please provide a definition, then.  I think it's very hard.
> 
> > And I do believe there will be practical cases (hopefully, very few
> > and far in-between) where we will need to make such reasoning, because
> > it's Emacs.
> 
> It's not clear to me what you're saying here: it's a design decision of
> scratch/igc that we'll fix those "practical" cases in another way.
> That's what we're doing now.
> 
> > So stating in a design document that this is impossible
> > is not useful, in addition to being false.
> 
> How about:
> 
> > The MPS-based GC in scratch/igc does not allow or require application
> > C code to make "no GC here" assumptions.
> 
> That's not false.  It's clearly a rule rather than a statement about
> when GC actually happens.  It's a very useful rule.  It isn't stated as
> elegantly as it is in the patch Stefan suggested, and leads to avoidable
> confusion.
> 
> I prefer Stefan's wording, but if you insist on reading that as a
> statement about when GC actually happens, rather than establishing a
> rule, we'll have to go with the more convoluted statement I suggested
> first.
> 
> Is your suggestion not to document this major design decision based on
> your belief that we'll have to revisit and alter it at some point in the
> future?  That doesn't make sense to me.
> 
> Or is your suggestion to alter the design decision now?

I don't see any reason to start a dispute about a single sentence.  I
think Stefan understood me, but if not, I'll gladly modify the wording
after it is installed.