Re: MPS: staticpro everything

[Eli Zaretskii <eliz@gnu.org>]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  eller.helmut@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 02 May 2024 16:01:42 +0200
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> > Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> >
> >> 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?
> >
> > You'll excuse me if I'm late to the party, but what becomes of strings
> > in cached bidi_its when MPS is in control?
> 
> bidi_cache is a global variable pointing to a malloc'd array of bidi_it.
> So, by itself, nothing is protected. MPS doesn't know anything about
> malloc'd memory.

That's true.  But the string Po Lu is alluding to is stored in the
cache as a Lisp object, not as a 'char *' pointer to the string's
data.  So as long as the string is alive (i.e. referenced from other
places), it should not be moved, right?

> For some reason, this works with the old GC, without the need for a
> special mark function, analogous to mark_specpdl, say. Why that is I
> have no idea. Something else apparently keeps everything in the cache
> alive.

That string is not just an arbitrary string, it's a string that the
display iterator is iterating.  So its reference is also in
it->string, which is on the C stack, and that reference keeps it alive
for as long as the string is being processed.  Once we are done
iterating the string, the parts of the cache that hold the states
related to that iteration are thrown away, because they are no longer
needed.

> (As I mentioned, using igc_xzalloc_ambig would do the trick. With the
> disadvantages Eli mentioned - scanning more than needed.)

I'd like to avoid that, of course.  We have only a single pointer to
'struct window', so scanning the entire cache is just waste of CPU
cycles.