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: /srv/bzr/emacs/emacs-24 r111116: eval-after-load fix Date: Fri, 04 Jan 2013 13:10:00 -0500 Message-ID: References: <878v8b839k.fsf@yandex.ru> <871ue3c5ek.fsf@uwakimon.sk.tsukuba.ac.jp> <50E669D2.6030808@yandex.ru> <87sj6hb4f0.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1357323008 8497 80.91.229.3 (4 Jan 2013 18:10:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Jan 2013 18:10:08 +0000 (UTC) Cc: emacs-devel@gnu.org, Dmitry Gutov To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 04 19:10:24 2013 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 1TrBio-00027L-Mz for ged-emacs-devel@m.gmane.org; Fri, 04 Jan 2013 19:10:22 +0100 Original-Received: from localhost ([::1]:38649 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TrBiZ-0004B0-Az for ged-emacs-devel@m.gmane.org; Fri, 04 Jan 2013 13:10:07 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:42009) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TrBiV-00048W-HS for emacs-devel@gnu.org; Fri, 04 Jan 2013 13:10:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TrBiT-0000gB-CU for emacs-devel@gnu.org; Fri, 04 Jan 2013 13:10:03 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:56606) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TrBiT-0000fZ-6t for emacs-devel@gnu.org; Fri, 04 Jan 2013 13:10:01 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkGAG6Zu09FxK5W/2dsb2JhbABEgXuyFoEIghUBAQQBViMFCws0EhQYDSSIHAW6CZBEA4hCmnGBWIMH X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="211409062" Original-Received: from 69-196-174-86.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([69.196.174.86]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 04 Jan 2013 13:10:00 -0500 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 2E957AE6AB; Fri, 4 Jan 2013 13:10:00 -0500 (EST) In-Reply-To: <87sj6hb4f0.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Fri, 04 Jan 2013 19:58:43 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 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:156082 Archived-At: > The arguments that killed purespace for us were (1) most users > (including most of those who argued for keeping purespace :-) are in > one-xemacs-process-per-machine workflows, and (2) in theory modern > virtual memory management by OSes (we were specifically influenced by > Linux and Windows) should produce most of the benefits of purespace > anyway, since the dumped code contains only a few writable objects, > and those tend to be clumped on a very few pages per file, such that > the potentially written pages might be measured in 100s of KB out of > the 3-5 MB (at that time) of XEmacs memory. > I'm not sure I believe (2), though. I also doubt 2 is true, unless XEmacs's object layout has been changed to move the markbit out of their objects. All live objects's markbits get written during a GC (except for purespace, of course), regardless of the object being read-only. But I don't see this sharing as tremendously important: we're talking about a purespace of about 2MB, for a process whose code size is larger and whose minimal runtime size is also a good bit larger. Negligible? I don't know! but not terribly important. OTOH the GC time at start up is reduced by almost a factor 3 (the Lisp heap size of "emacs -Q" is about 1MB, whereas it'd be around 3MB if it weren't for the purespace). On the third hand, this Gnus process has a Lisp heap size of about 100MB, so the purespace makes virtually no difference (we'd need a generational GC, instead). Stefan