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: t and nil in pure memory? Date: Wed, 11 Nov 2009 17:56:34 -0500 Message-ID: References: <200911112023.nABKNrH6023933@godzilla.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1257980214 28566 80.91.229.12 (11 Nov 2009 22:56:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Nov 2009 22:56:54 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dan Nicolaescu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 11 23:56:47 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1N8M7K-00028z-HV for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2009 23:56:46 +0100 Original-Received: from localhost ([127.0.0.1]:39496 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8M7K-0002qK-0h for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2009 17:56:46 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N8M7F-0002pu-6h for emacs-devel@gnu.org; Wed, 11 Nov 2009 17:56:41 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N8M7A-0002oW-0l for emacs-devel@gnu.org; Wed, 11 Nov 2009 17:56:40 -0500 Original-Received: from [199.232.76.173] (port=50721 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8M79-0002oT-Ro for emacs-devel@gnu.org; Wed, 11 Nov 2009 17:56:35 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:64465 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N8M79-0003Oa-EH for emacs-devel@gnu.org; Wed, 11 Nov 2009 17:56:35 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAAzQ+kpMCpsp/2dsb2JhbACBTdwFhDwEiSOCeA X-IronPort-AV: E=Sophos;i="4.44,726,1249272000"; d="scan'208";a="49136901" Original-Received: from 76-10-155-41.dsl.teksavvy.com (HELO pastel.home) ([76.10.155.41]) by ironport2-out.pppoe.ca with ESMTP; 11 Nov 2009 17:56:34 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 5680F8373; Wed, 11 Nov 2009 17:56:34 -0500 (EST) In-Reply-To: <200911112023.nABKNrH6023933@godzilla.ics.uci.edu> (Dan Nicolaescu's message of "Wed, 11 Nov 2009 12:23:53 -0800 (PST)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:116850 Archived-At: > The last GC before dumping generates 200K calls to mark_object, of those > 20K have Qt or Qnil as an argument. > Would it make sense to put Qt and Qnil in pure memory? No, because they may contain pointers to objects that aren't in pure memory (via the plist). > Moving Qt and Qnil in pure memory would break things like: > (put t 'foo 'bar) Exactly. > but maybe this works by accident rather than design. No, it's no accident. > More generally it would be very good to be able to put symbols in pure > memory, about 1/3 of the mark_object calls are for symbols, and it does > not seem that it's too useful to GC `car', `cdr', etc. But it does not > seem to be too easy to do :-( Since symbols have mutable fields that can contain pointers, it's important to let the GC trace through them. If we want to speed up the GC, then we should look at changing the algorithm (e.g. make it generational). Maybe we can also micro-optimize the code to let it run faster: we could probably make `mark_object' into a macro that first checks the markbit and only if that fails does it call really_mark_object recursively. Of course, tests would be needed to try and figure out whether it really makes things faster. Stefan