Re: MPS: pdump

[Eli Zaretskii <eliz@gnu.org>]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 02 May 2024 21:45:55 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> 
> >> If initial_frame is an object in H', fix_frame won't be called for it.
> >> It cannot because the dump is not part of the MPS memory, and is instead
> >> traced ambigously as part of the big blob H'.
> >
> > If the face cache of the initial frame is the problem, we can simply
> > forget about it, and create a completely new face cache for it.  The
> > face cache that existed during dumping doesn't matter (it probably
> > contains only the basic faces anyway).
> >
> > So how about just calling init_frame_faces for the initial frame, in
> > some init_SOMETHING function called at startup?  Like in init_xfaces,
> > for example?
> 
> That would unfortunately not help:
> 
> If something in the face cache contains references, we must scan it.

Yes, but what are those "somethings" in the particular case of the
face cache of the initial frame?  Here's what I see:

  struct face_cache
  {
    /* Hash table of cached realized faces.  */
    struct face **buckets;

    /* Back-pointer to the frame this cache belongs to.  */
    struct frame *f;

    /* A vector of faces so that faces can be referenced by an ID.  */
    struct face **faces_by_id;

    /* The allocated size, and number of used slots of faces_by_id.  */
    ptrdiff_t size;
    int used;

    /* Flag indicating that attributes of the `menu' face have been
       changed.  */
    bool_bf menu_face_changed_p : 1;
  };

The only members of importance to us are the back-pointer to the
frame, the buckets array, and the faces_by_id array.  Do you agree?

The frame pointer should not be a problem, since Vterminal_frame
should be traced (if it isn't already) -- it is a global Lisp object,
and we agreed those should be staticpro'd.

The two 'struct face' arrays should not be a problem, because calling
init_frame_faces, as I suggested, will recreate the basic faces anew
(we can call free_all_realized_faces if the recreation will not happen
otherwise).

So what "somethings" could be a problem here, and why?

> We
> won't because we don't trace initial_frame, we only scan it ambigupusly
> as an anonymous part of the big blob H', and the pointer to the
> face_cache is just some random uninteresting pointer. In the end, we'll
> never scan the face_cache.

How is the case of the initial frame different from any other frame we
create after loading the dump file?  I feel there's some
misunderstanding here, most probably mine.

> In some other cases (itree_node, itree_tree, ...) I've made the
> corresponing structs MPS-managed. With this, when we scan H', we'll find
> a pointer to an MPS-managed object and MPS can tell if a pointer is to
> one of its objs. We'd need a new IGC_OBJ_FACE_CACHE for that, or
> something like it if we already have too many.

I don't think I understand this, probably because I need the above
question answered first.