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 21:06:46 +0400 Message-ID: <5048D826.3040103@yandex.ru> References: <504848D0.4020908@yandex.ru> 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 1346951229 3268 80.91.229.3 (6 Sep 2012 17:07:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Sep 2012 17:07:09 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 06 19:07:12 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 1T9fXo-0001T4-MV for ged-emacs-devel@m.gmane.org; Thu, 06 Sep 2012 19:07:08 +0200 Original-Received: from localhost ([::1]:52482 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9fXk-00010u-MV for ged-emacs-devel@m.gmane.org; Thu, 06 Sep 2012 13:07:04 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:47685) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9fXa-00010T-Kj for emacs-devel@gnu.org; Thu, 06 Sep 2012 13:07:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T9fXU-0008DR-Kh for emacs-devel@gnu.org; Thu, 06 Sep 2012 13:06:54 -0400 Original-Received: from forward8.mail.yandex.net ([77.88.61.38]:56450) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9fXU-0008DM-8I for emacs-devel@gnu.org; Thu, 06 Sep 2012 13:06:48 -0400 Original-Received: from smtp9.mail.yandex.net (smtp9.mail.yandex.net [77.88.61.35]) by forward8.mail.yandex.net (Yandex) with ESMTP id 9AA3EF61074; Thu, 6 Sep 2012 21:06:46 +0400 (MSK) Original-Received: from smtp9.mail.yandex.net (localhost [127.0.0.1]) by smtp9.mail.yandex.net (Yandex) with ESMTP id 73B7A1520780; Thu, 6 Sep 2012 21:06:46 +0400 (MSK) Original-Received: from unknown (unknown [37.139.80.10]) by smtp9.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 6j08lOph-6k0inUBB; Thu, 6 Sep 2012 21:06:46 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1346951206; bh=5kgeyuPFKl2TUdSYETWQDX5DOtoLKhPOKYsN6xpydC0=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Xs3qH48bL/nlZJtiBM2oPHDhyuHRJeZPuPVdRVxSpKvEi896425b48U9i3w+plPnh Hnmf6zae+BShvKilSwrdHGV4WCvcAmNeZnXgCg4NdQw7FLhGfDDaGIJYAU+gROoNIa DYH17Z58IDdF+ooE9B155hrxkH0OaMjdnKY1R0rE= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120824 Thunderbird/15.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 77.88.61.38 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:153118 Archived-At: On 09/06/2012 04:52 PM, Stefan Monnier wrote: > I don't see anything that needs fixing here. On the contrary. It can > be very useful to keep a reference to a frame/window, and when you need > to display data, see if it's still live, and if not create a new one, > initializing some of its parameters from the old deleted one. Yes, this is an contrary solution which has it's own advantages; but currently we have nothing similar neither for buffers nor for frames. >> 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; > > In 99% of the cases, it's easy to distinguish: one can be GC'd and the > other can't. From GC's point of view; if you look at window pointer and W->hchild, W->vchild and W->buffer are all Qnil, you still don't know whether W is recorded in some window configuration object. >> 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). > > So, that's the problem you're attacking. Fine, but please: Yes, an idea comes after looking at dead buffers which are still chained among live ones at all_buffers. > 1- Check how much extra data is really kept live because of this. > As you mention, it may be a lot less than it appears at first. > 2- Check how much longer it's kept alive. > 4- Check which fields of the buffer keep that data alive. > 3- Check why the buffer itself is kept alive: maybe the better fix is to make > it so the buffer can be GC'd. OK >> 2) IMHO this is conceptually wrong and > > I strongly disagree. I think you have an incorrect understanding of > what a "deleted/killed" object is. It really isn't dead at all. Hm... it was definitely wrong for the windows because deleted window may be "a little more alive" than deleted buffer or frame; but I still think that treating "deleted/killed" object as "dead enough to not look inside too much" is good enough for the rest. Dmitry