Re: MPS: struct window, prev_buffers + next_buffers

[Eli Zaretskii <eliz@gnu.org>]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: emacs-devel@gnu.org,  eller.helmut@gmail.com
> Date: Sat, 22 Jun 2024 10:13:33 +0200
> 
> 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.

Can't you write some simple code to count them?  A killed buffer has
its name nil, so it is easy to spot (we also have BUFFER_LIVE_P).  We
also have window-next-buffers and window-prev-buffers that return
these two lists.

> 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 think the use case is that you visit a file in a window, and then
kill it after some time.  Do that several times, switching between
buffers in between, and you should have those killed buffers in the
prev_buffers and next_buffers lists of the window.

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

Yes, you should do that in a single window to see the effect, I think.

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

But the code doesn't GC buffers, it just removes them from the
prev_buffers and next_buffers lists.  If a cons cell of the list is
marked, removing the buffer (which could subsequently lead to GC'ing
the buffer) might not be expected by the code which uses data that
references that buffer, even though the buffer is killed.