Re: MPS: staticpro everything

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: gerd.moellmann@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 01 May 2024 08:53:31 +0200
> 
> On Tue, Apr 30 2024, Eli Zaretskii wrote:
> 
> >> These probably need special tracing code:
> >> 
> >> bidi.c: bidi_cache
> >
> > Can you tell why?  The bidi cache is allocated using xmalloc, and has
> > a single Lisp string object in each of its slots.  The Lisp string
> > doesn't need any special handling, AFAIU, or does it?
> 
> The struct bidi_it has a pointer to a window.

'struct bidi_it' is a member of 'struct it', the iterator object we
use to perform display layout of windows.  'struct it' includes
pointers to the window being displayed and also to the frame of that
window:

  struct it
  {
    /* The window in which we iterate over current_buffer (or a string).  */
    Lisp_Object window;
    struct window *w;

    /* The window's frame.  */
    struct frame *f;

It also has a few other pointers.  And yet, you didn't include 'struct
it' in your list, and I wonder why the difference?  (The pointer to
the window is the same pointer that is copied in 'struct bidi_it'.)

This goes back to my other questions about MPS GC: which pointers to
what objects should be audited for possible need of "doing something"?
I think we need to discuss this right now, because otherwise we might
be wasting our time and energy on something that is simply unworkable
in Emacs, at least unless we rewrite most of our C code where it
accesses Lisp objects.

Emacs has a lot of code that is mostly straightforward when the
"normal" C runtime is used, with its mostly unmovable allocated
memory, but it could become very tricky if allocated memory can move
from under our feet at any given moment.  No one of us remembers or
even knows about all the places where we did some C trickery that can
become unworkable when some basic assumptions are invalidated.  So
even to think about these issues, so we could bring our combined
knowledge and experience to bear, requires that the issues are well
understood and clear, and their implications on Emacs object system
are also clear.  Only given such understanding can each one of us
consider the parts of the code he or she is familiar with, and think
whether any of them need adjustments.

> I think something needs to be done about that.  I didn't know what,
> so I made a note "for later".  I don't see the string you're talking
> about but I don't actually understand what this code does.  I just
> looked at the types.

I do understand what the code does, but I need to understand better
why having a pointer to a 'struct window' could be a reason "to do
something" about it.

> >> buffer.c: overlay_heads overlay_tails
> >> dispnew.c: frame_matrix_frame
> >> fns.c: hash_table_user_tests
> >> font.c: font_driver_list
> >
> > I thought we decided that font_driver_list didn't need any special
> > handling, as it's a simple C linked list?
> 
> Then maybe a comment would be appropriate.  Usually, any root needs to
> be traced.

What is "a root" in this context?  I though only roots of Lisp objects
are alluded to by this term, and font_driver_list is not a Lisp
object.