Re: Collecting markers with MPS

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.

Exactly! Glad that you look at this!

>> 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.

Makes sense to me, but I must say that I have 0 experience with that
using MPS. It might require some experimentation how to about
implementing such weak references, but that could be fun.

Let me give Eli a brief overview what MPS has.

MPS support weak references. Objects containing weak references must be
allocated from a special type of memory pool, which MPS calls AWL pools
(= Automantic Weak Linked pool or so). Such a pool, and MPS allocatioin
points are already there in igc.

An object in AWL can contain references, but these references must
either all be weak or all be strong.

(That's okay for weak hash tables, where all keys are weak/strong or all
values are weak/strong references. Which, BTW, is the reason why I split
key_and_value into two vectors in the branch.)

>> On the plus side, explicit weak reference objects could make some things
>> easier to understand and might be more widely useful to Lisp
>> programmers.

Yes, I'd find that a big plus, too.

>> What do you think?  Is there an more elegant alternative?

Can't think of one. 

> 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?

Yes, it makes sense. One could of course use a timer. Or maybe, don't
know, run something when we handle an MPS message. That just occurred to
me a second ago, so it might be nonsense.

But Helmut's idea _is_ pretty elegant and appealing I must say. And it
relieves the client of some more work (with the idea of improved
responsiveness...).