From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109898: * alloc.c (mark_object): Revert window marking code Date: Fri, 07 Sep 2012 11:10:47 -0400 Message-ID: References: <5049A28B.2050506@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1347030665 20739 80.91.229.3 (7 Sep 2012 15:11:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Sep 2012 15:11:05 +0000 (UTC) Cc: Emacs development discussions To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 07 17:11:05 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 1TA0Cx-0007Tw-Sk for ged-emacs-devel@m.gmane.org; Fri, 07 Sep 2012 17:11:00 +0200 Original-Received: from localhost ([::1]:60150 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TA0Cu-0006VY-MN for ged-emacs-devel@m.gmane.org; Fri, 07 Sep 2012 11:10:56 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:50980) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TA0Cn-0006VR-N1 for emacs-devel@gnu.org; Fri, 07 Sep 2012 11:10:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TA0Cm-0003Ih-EL for emacs-devel@gnu.org; Fri, 07 Sep 2012 11:10:49 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:50723) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TA0Cm-0003Ic-8P for emacs-devel@gnu.org; Fri, 07 Sep 2012 11:10:48 -0400 Original-Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id q87FAl01004085; Fri, 7 Sep 2012 11:10:47 -0400 Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 66AE4B4085; Fri, 7 Sep 2012 11:10:47 -0400 (EDT) In-Reply-To: <5049A28B.2050506@yandex.ru> (Dmitry Antipov's message of "Fri, 07 Sep 2012 11:30:19 +0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Received-From: 132.204.246.22 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:153152 Archived-At: > BTW, are there any reasons to reset local variables in Fkill_buffer? It sets the buffer-local slots to the global value, so from the GC's behavior point of view, it's the same as setting them to Qnil since those values will be live anyway. IOW using reset_buffer_local_variables should have pretty much the same effect as your new nullify_buffer, except for the few fields it might miss. BTW, have you tried to figure out what keeps those buffers/frames/windows live? > +/* Set all F's Lisp_Object slots to nil in attempt to let > + GC to sweep them early. Setting f->terminal to NULL > + makes FRAME_LIVE_P false for this frame. */ > + > +static inline void > +nullify_frame (struct frame *f) > +{ > + Lisp_Object *ptr; > + > + for (ptr = &f->name; ptr <= &f->current_tool_bar_string; ptr++) > + *ptr = Qnil; > + f->terminal = NULL; > +} > + > /* Delete FRAME. When FORCE equals Qnoelisp, delete FRAME > unconditionally. x_connection_closed and delete_terminal use > this. Any other value of FORCE implements the semantics > @@ -1321,7 +1335,9 @@ > { > struct terminal *terminal = FRAME_TERMINAL (f); > f-> output_data.nothing = 0; > - f->terminal = 0; /* Now the frame is dead. */ > + > + /* F is really dead after this. */ > + nullify_frame (f); I actually prefer having the f->terminal=NULL where it was, so that nullify_frame really only affects the GC behavior and is otherwise unnoticeable. Same for nullify_buffer. Stefan