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

[Dmitry Antipov]

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 
Lisp_Objects
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 
W->pointm).

Dmitry