[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 10:55:12 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120824 Thunderbird/15.0

On 09/05/2012 10:24 PM, Stefan Monnier wrote:

I'm not sure this is safe.  Such deleted objects are still perfectly
live from the memory-allocation point of view, and while some operations
on them are disallowed "for ever", there are others that might still be
permitted and which may still access internal data.

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

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.

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; but this requires a kind of
finalization for saved_window_data objects (when such an object dies,
it's finalizer should clear corresponding bits in all recorded windows).
Since we can't implement this just now, I'm reverting window marking;
but I think that I'll spent more time on this :-).

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

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; 2) IMHO this is conceptually
wrong and 3) it still has it's own traps (for example, if we set all 
slot of the deleted window to Qnil, set-window-configuration will not work since
it assumes that the restored window has valid marker objects at W->start and 


reply via email to

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