[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109890: Do not mark objects from

From: Dmitry Antipov
Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109890: Do not mark objects from deleted buffers, windows and frames.
Date: Thu, 06 Sep 2012 21:06:46 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120824 Thunderbird/15.0

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

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.


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]