Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109890: Do not mark objects from deleted buffers, windows and frames.

[Dmitry Antipov]

On 09/06/2012 04:52 PM, Stefan Monnier wrote:
> I don't see anything that needs fixing here.  On the contrary.  It can
> be very useful to keep a reference to a frame/window, and when you need
> to display data, see if it's still live, and if not create a new one,
> initializing some of its parameters from the old deleted one.

Yes, this is an contrary solution which has it's own advantages; but
currently we have nothing similar neither for buffers nor for frames.

> > The only important exception is saving/restoring window configurations.
> > Strictly speaking, if the window configuration is recorded in
> > saved_window_data, such a window is not deleted.  Ideally, struct
> > window should have a bit indicating that it's configuration is
> > recorded so such a window can be distinguished from the really dead
> > windows;
>
> In 99% of the cases, it's easy to distinguish: one can be GC'd and the
> other can't.

From GC's point of view; if you look at window pointer and W->hchild,
W->vchild and W->buffer are all Qnil, you still don't know whether W
is recorded in some window configuration object.

> > Hm.  For example, killed buffers may sit in all_buffers for a while,
> > and still have from tens to thousands reachable objects per buffer
> > (although I didn't check whether these objects are reachable only from
> > this dead buffer).
>
> So, that's the problem you're attacking.  Fine, but please:

Yes, an idea comes after looking at dead buffers which are still chained
among live ones at all_buffers.

> 1- Check how much extra data is really kept live because of this.
>     As you mention, it may be a lot less than it appears at first.
> 2- Check how much longer it's kept alive.
> 4- Check which fields of the buffer keep that data alive.
> 3- Check why the buffer itself is kept alive: maybe the better fix is to make
>     it so the buffer can be GC'd.

OK

> > 2) IMHO this is conceptually wrong and
>
> I strongly disagree.  I think you have an incorrect understanding of
> what a "deleted/killed" object is.  It really isn't dead at all.

Hm... it was definitely wrong for the windows because deleted window
may be "a little more alive" than deleted buffer or frame; but I still think
that treating "deleted/killed" object as "dead enough to not
look inside too much" is good enough for the rest.

Dmitry