Re: MPS: struct window, prev_buffers + next_buffers

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, Helmut Eller <eller.helmut@gmail.com>
>> Date: Sat, 22 Jun 2024 09:24:59 +0200
>> 
>> 1. Does igc really have to do something? I don't see something
>> noticeably growing, even after hours of using Emacs with igc.
>
> How many buffers did that session create and delete?  Do you see
> killed buffers not collected (i.e. buffer objects whose name is nil
> that are not garbage-collected because the window's prev_buffers or
> next_buffers list references those killed buffers?  That's what the
> comment in mark_window says:

How many buffers get killed is hard to tell. I have usually 50-100 file
buffers, which are kind of long-lived, plus constantly temp buffers (I
guess) that are created by vertico and alike.

I've not noticed that the number of buffers increases noticeably. There
is always some variation that I would expect from conservative roots, of
course, control stack and alike.

Maybe it's because windows aren't long-lived? No idea.

>
>   /* Filter out killed buffers from both buffer lists
>      in attempt to help GC to reclaim killed buffers faster.
>      We can do it elsewhere for live windows, but this is the
>      best place to do it for dead windows.  */
>   wset_prev_buffers
>     (w, mark_discard_killed_buffers (w->prev_buffers));
>   wset_next_buffers
>     (w, mark_discard_killed_buffers (w->next_buffers));
>
>> 2. Is it an option to leaving these lists alone in GC?
>
> Isn't this the same question as 1, just IOW?

Maybe :-)

>> 3. If igc should do something, how frequently? IOW what makes these
>> lists grow? And perhaps could we do this cleanup where new entries are
>> pushed onto them?
>
> The growth of these lists is not the problem, I think.  The problem is
> that they reference killed buffers, and that prevents those killed
> buffers from being GCed.
>
>> 4. Note that the loop in the function stops when a cons cell is marked.
>> So it doesn't always take entries off the list that contain dead
>> buffers. I don't understand that at all.
>
> I guess the cons cell being marked means that someone has a reference
> to it, and therefore it cannot be GCed?

But it won't be GC'd anyway, becuase it's marked. And if the buffer in
the cons is killed, it remains in the list. That makes no sense to me.