From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Antipov Newsgroups: gmane.emacs.devel 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 Message-ID: <5048739E.80005@yandex.ru> References: <504848D0.4020908@yandex.ru> <504850B4.7020002@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1346925491 27509 80.91.229.3 (6 Sep 2012 09:58:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Sep 2012 09:58:11 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 06 11:58:13 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1T9Yqe-0004Sx-Rz for ged-emacs-devel@m.gmane.org; Thu, 06 Sep 2012 11:58:08 +0200 Original-Received: from localhost ([::1]:36032 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9Yqc-0006Eh-0y for ged-emacs-devel@m.gmane.org; Thu, 06 Sep 2012 05:58:06 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42645) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9YqU-000684-LV for emacs-devel@gnu.org; Thu, 06 Sep 2012 05:58:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T9YqO-0005Mh-Q6 for emacs-devel@gnu.org; Thu, 06 Sep 2012 05:57:58 -0400 Original-Received: from forward9.mail.yandex.net ([77.88.61.48]:33199) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9YqO-0005MQ-E4 for emacs-devel@gnu.org; Thu, 06 Sep 2012 05:57:52 -0400 Original-Received: from smtp9.mail.yandex.net (smtp9.mail.yandex.net [77.88.61.35]) by forward9.mail.yandex.net (Yandex) with ESMTP id A84F0CE071C; Thu, 6 Sep 2012 13:57:50 +0400 (MSK) Original-Received: from smtp9.mail.yandex.net (localhost [127.0.0.1]) by smtp9.mail.yandex.net (Yandex) with ESMTP id 73C641520736; Thu, 6 Sep 2012 13:57:50 +0400 (MSK) Original-Received: from unknown (unknown [37.139.80.10]) by smtp9.mail.yandex.net (nwsmtp/Yandex) with ESMTP id vnw82JfT-vnwKaJuU; Thu, 6 Sep 2012 13:57:49 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1346925470; bh=iuWC+RdXW92bRNo1W2Ui4D0piG/r/jq0V2nxqtdTq4s=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=XbhQYoGfWgDMCa6WrbvDu42B/bB+0GtHP3gUzJ8ZVzSS1HOP9hilGaXPPXivWkQCC cD4D+S5M0f3vQDmKjSq77s3bMOwcfRr9LbrahSoqCoypWBLhzzn6AOIsHFMue5gWaG BMrpY7GSiWu7BfGE7vZFYCoM/dl2LDMXScNFbkOc= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120824 Thunderbird/15.0 In-Reply-To: <504850B4.7020002@gmx.at> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 77.88.61.48 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:153100 Archived-At: 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 ;-) OK > > 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: Fset_window_configuration: ... 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 */ w->buffer); 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. Dmitry