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

[Stefan Monnier]

> IMHO such an operations shouldn't make any assumptions about internal
> fields of the deleted objects.  The only possible exception is NILP
> (obj->field) since this may be used to distinguish between live and
> dead objects (as we have now for the buffers and windows).

No, there can be perfectly valid reasons to access
a deleted/killed object.

>> E.g. you might still be able to get (window|frame)-parameters of
>> a deleted (window|frame).
> I'm pretty sure that this is invalid and should be fixed.

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.

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

>> IOW, it adds lines of code, makes the invariants more complex (in ways
>> which I'm not sure is currently ensured by the rest of the code) and the
>> benefits aren't obvious at all.
> 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:
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.

>> I don't think scanning those objects can take a noticeable amount of
>> time, so the only potential issue is holding on to data that can never
>> be used again, in which case I'd much prefer changing
>> kill-buffer/delete-(window|frame) so they set the various fields to
>> NULL/nil.  Which is a much safer change.

> I agree about the safety, but:
> 1) this is slower;

Yes, it could be slower, tho I expect there are only a few slots that
would need such a treatment, so I don't think it would be noticeable.

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

> 3) it still has it's own traps.

Obviously, we don't want to NULL/nil all fields blindly.  We want to do
it parsimoniously, so that we only do it for fields which we know can
safely be set this way, and ideally only for fields which do hold on to
too much data (e.g. not for fields which only contain numbers anyway).


        Stefan