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

On 09/06/2012 11:28 AM, martin rudalics wrote:

 > Since we can't implement this just now, I'm reverting window marking;
 > but I think that I'll spent more time on this :-).

... and please tell the people from bug 12251 about it ;-)


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

Could you elaborate?

Elaborate what? I tried to count calls to mark_object needed to mark the buffer
and all data referenced from it, and it may be from 60-70 to a few thousands or
even more; some of these calls are no-ops since corresponding objects may be
marked already or doesn't need marking at all.

Marker objects belong to the buffer.

Not all - make_window attaches two new markers to W->start and W->pointm; when W
is set up to display the buffer B (set_window_buffer or maybe somewhere else),
these markers are changed from 'point to nowhere' to 'point into B'.

The start and pointm fields are
regenerated from the saved window structure.

Their member values are regenerated assuming that W->start and W->pointm itself
are valid marker objects:

else if (!NILP (BVAR (XBUFFER (p->buffer), name)))
  /* If saved buffer is alive, install it.  */
    wset_buffer (w, p->buffer);
    w->start_at_line_beg = !NILP (p->start_at_line_beg);
    set_marker_restricted (w->start, p->start, w->buffer);  /* here */
    set_marker_restricted (w->pointm, p->pointm,            /* and here */
    Fset_marker (BVAR (XBUFFER (w->buffer), mark),
                 p->mark, w->buffer);

This will throw an error if start/pointm aren't markers, or crash
if they're invalid or uninitialized; if we can't trust the values
stored in W's fields, we should use Fcopy_marker instead.


reply via email to

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