Re: Collecting markers with MPS (was: STatus of MPS branch)

[Eli Zaretskii <eliz@gnu.org>]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: emacs-devel <emacs-devel@gnu.org>
> Date: Wed, 24 Apr 2024 09:26:08 +0200
> 
> On Sat, Apr 20 2024, Gerd Möllmann wrote:
> 
> > - Figure out what is done in the old GC in garbage_collect that is not
> >   directly related to GC, and how to do that when GC is concurrent.
> >   Examples are buffer undo_list, window prev_buffers/next_buffers
> 
> In the igc branch, markers are currently not collected because they are
> referenced from the buffer's chain of markers.  The old GC has special
> code to break this link.  There is also special code to break links from
> the undo-list to markers.
> 
> With the MPS, we could introduce explicit weak reference objects,
> similar to WeakRef in Javascript[*].  Buffers would then, instead of the
> current chain of markers, have a list of weak references to markers.
> (Markers would no longer have the embedded "next" field.)  The same for
> the undo-list: instead of markers, it would contain weak references to
> markers.
> 
> This would allow markers to be collected, but the empty weak-ref objects
> would still be in the undo-list and the buffer's markers-list.  A timer
> could periodically go through those lists and remove the empty
> weak-refs.
> 
> Does this sound like a reasonable plan?  To me, it sounds like it will
> require relatively big changes to the buffer code.  Much bigger than the
> 200 or so lines of special code in the old GC.  Also, the undo-list is
> visible to Lisp code, so those weak reference objects in there must be
> new types of Lisp objects.
> 
> On the plus side, explicit weak reference objects could make some things
> easier to understand and might be more widely useful to Lisp
> programmers.
> 
> What do you think?  Is there an more elegant alternative?

My opinions here mean very little for now, as I don't yet have a good
view of the issues, but in general: why do we have to do everything
the old GC did in the new GC?  Can't we leave some of the stuff to be
done in the main thread?  For example, the old GC would compact buffer
text, Lisp strings, and font caches -- this cannot be done from a
different thread, AFAIU.  Why not keep doing this from the main
thread, like we do now?  They are not really directly relevant to GC,
just some housekeeping tasks that need to be done from time to time.
Yes, it would mean the main thread still needs to stop from time to
time, but for much shorter periods of time.  And it will allow us to
sidestep the significant changes like those mentioned above, some of
which would mean Lisp-level changes that will affect Lisp programs.

If leaving some of this stuff in the main thread is reasonable, we
could add the above two jobs to that part, which would allow us to
leave the existing related code almost intact.

Does this make sense?