From: Dmitry Antipov <dmantipov@yandex.ru>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
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 [thread overview]
Message-ID: <504848D0.4020908@yandex.ru> (raw)
In-Reply-To: <jwvwr08xrip.fsf-monnier+emacs@gnu.org>
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
next prev parent reply other threads:[~2012-09-06 6:55 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1T9II0-0005q4-Gh@vcs.savannah.gnu.org>
2012-09-05 18:24 ` [Emacs-diffs] /srv/bzr/emacs/trunk r109890: Do not mark objects from deleted buffers, windows and frames Stefan Monnier
2012-09-05 19:15 ` Stefan Monnier
2012-09-06 6:55 ` Dmitry Antipov [this message]
2012-09-06 7:00 ` Herring, Davis
2012-09-06 7:28 ` martin rudalics
2012-09-06 9:57 ` Dmitry Antipov
2012-09-06 14:42 ` martin rudalics
2012-09-06 12:53 ` Stefan Monnier
2012-09-06 14:42 ` martin rudalics
2012-09-06 12:52 ` Stefan Monnier
2012-09-06 14:42 ` martin rudalics
2012-09-06 17:33 ` Stefan Monnier
2012-09-07 9:52 ` martin rudalics
2012-09-06 17:06 ` Dmitry Antipov
2012-09-06 17:37 ` Stefan Monnier
2012-09-07 9:53 ` martin rudalics
2012-09-07 15:19 ` Stefan Monnier
2012-09-10 9:46 ` Reachable killed buffers [Was: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109890: Do not mark objects from deleted buffers, windows and frames] Dmitry Antipov
2012-09-10 13:25 ` Stefan Monnier
2012-09-10 15:15 ` Reachable killed buffers Dmitry Antipov
2012-09-10 20:15 ` Stefan Monnier
2012-09-10 21:10 ` Stefan Monnier
2012-09-11 5:25 ` Dmitry Antipov
2012-09-11 13:06 ` Stefan Monnier
2012-09-12 8:09 ` martin rudalics
2012-09-12 13:47 ` Paul Eggert
2012-09-12 13:59 ` Dmitry Antipov
2012-09-12 14:05 ` Paul Eggert
2012-09-12 14:15 ` martin rudalics
2012-09-12 15:59 ` Dmitry Antipov
2012-09-12 17:37 ` martin rudalics
2012-09-12 17:55 ` Paul Eggert
2012-09-13 3:29 ` Stefan Monnier
2012-09-13 4:43 ` Paul Eggert
2012-09-13 5:00 ` Dmitry Antipov
2012-09-13 5:18 ` Paul Eggert
2012-09-13 12:47 ` Stefan Monnier
2012-09-13 16:49 ` martin rudalics
2012-09-13 17:11 ` Paul Eggert
2012-09-13 17:30 ` martin rudalics
2012-09-14 12:10 ` Dmitry Antipov
2012-09-14 13:29 ` Stefan Monnier
2012-09-14 13:38 ` martin rudalics
2012-09-13 18:01 ` Dmitry Antipov
2012-09-06 7:20 ` [Emacs-diffs] /srv/bzr/emacs/trunk r109890: Do not mark objects from deleted buffers, windows and frames martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=504848D0.4020908@yandex.ru \
--to=dmantipov@yandex.ru \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.