Re: MPS: staticpro everything

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 02 May 2024 14:30:01 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > But doesn't that mean MPS will need to trace too much?
> >> 
> >> Yes, admitted :-). We could optimize that later...
> >
> > It also means (AFAIU) that every cache slot that is "freed" by moving
> > bidi_cache_idx back will need to have the 'struct window *' member be
> > set to NULL, to prevent MPS from tracing garbage.  Right?  I'd like to
> > avoid these complications, if only for performance reasons.
> 
> Right, that's true.

So it's another complication.  Right now, the function that "frees"
the cache is very simple and fast:

  static void
  bidi_cache_reset_to (int n)
  {
    bidi_cache_idx = bidi_cache_start + n;
    bidi_cache_last_idx = -1;
  }
  static void
  bidi_cache_reset (void)
  {
    bidi_cache_reset_to (0);
  }

If we go the igc_xzalloc_ambig route, then not only will we be wasting
CPU cycles on zeroing-out of the cache each time we (re)allocate it,
but we will also need to waste CPU cycles on zeroing them out in the
above functions.  If that can be avoided, I'd prefer to.

> >> I'm sorry, I don't remember. What was the idea again?
> >
> > Make it so the window being processed by redisplay_window is
> > unmovable.  That is the window whose pointer bidi_it uses.  But I also
> > think doing this will be useful for other reasons, since the display
> > code manipulates the it->w pointer quite liberally, and who knows what
> > we do with it?  If the window cannot move while it is being
> > redisplayed, we can stop bothering about all those uses of its
> > pointer.
> 
> Yes.

That should be very easy to do, then.  Can you tell me how I make a
struct unmovable by MPS, when I have a pointer to the struct in hand?

> I now wonder: If struct it always lives on the stack (I think that's still
> true?), then it->w is also on the stack, and thus it->w is immovable by
> fact fact. Right?

Yes.  So you are saying there's no problem, neither with it->w, nor
with it->bidi_it.w, and thus the cached bidi_it objects are also safe
in this aspect?