From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109187: Adjust consing_since_gc when objects are explicitly freed. Date: Mon, 23 Jul 2012 20:10:56 +0900 Message-ID: <87629e3f7j.fsf@uwakimon.sk.tsukuba.ac.jp> References: <500D18D4.7010506@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: dough.gmane.org 1343041884 12866 80.91.229.3 (23 Jul 2012 11:11:24 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 23 Jul 2012 11:11:24 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 23 13:11:23 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 1StGXo-0004QI-4t for ged-emacs-devel@m.gmane.org; Mon, 23 Jul 2012 13:11:20 +0200 Original-Received: from localhost ([::1]:35963 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1StGXk-0002PL-7d for ged-emacs-devel@m.gmane.org; Mon, 23 Jul 2012 07:11:16 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:34288) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1StGXd-0002Ov-2d for emacs-devel@gnu.org; Mon, 23 Jul 2012 07:11:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1StGXZ-0006Fx-2F for emacs-devel@gnu.org; Mon, 23 Jul 2012 07:11:08 -0400 Original-Received: from mgmt1.sk.tsukuba.ac.jp ([130.158.97.223]:53783) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1StGXY-0006Ez-Of for emacs-devel@gnu.org; Mon, 23 Jul 2012 07:11:04 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id C01933FA0862; Mon, 23 Jul 2012 20:10:56 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 87C571A33AD; Mon, 23 Jul 2012 20:10:56 +0900 (JST) In-Reply-To: <500D18D4.7010506@yandex.ru> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta31) "ginger" b4715fcbe001 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.158.97.223 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:151814 Archived-At: Dmitry Antipov writes: > IMHO, mostly because consing_since_gc means "total size of new objects which > are managed by GC". If we manage some of them by hand, we shouldn't allow GC > to overestimate an amount of work to be done. Why is it an overestimate of the work to be done? AFAIK, these objects come from the same pools, and they are not necessarily short- lived in the sense that they are allocated and deallocated before other objects become allocated. If my assumption about the memory pools is correct, a no-see-um cons is just as likely to overflow a pool, and somewhat likely to contribute to overflow of later allocations. If it's a container and live when GC occurs, it will need to be traversed. So it does contribute to the work to be done, although not as likely to contribute as GC-managed objects are.