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: Fri, 13 Nov 2009 09:39:19 -0500 Message-ID: References: <200911112023.nABKNrH6023933@godzilla.ics.uci.edu> <87pr7oxieq.fsf@freebits.de> <200911130524.nAD5O5uu009102@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 1258123178 6901 80.91.229.12 (13 Nov 2009 14:39:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Nov 2009 14:39:38 +0000 (UTC) Cc: "Tobias C. Rittweiler" , emacs-devel@gnu.org To: Dan Nicolaescu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 13 15:39:31 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 1N8xJC-00052P-G4 for ged-emacs-devel@m.gmane.org; Fri, 13 Nov 2009 15:39:30 +0100 Original-Received: from localhost ([127.0.0.1]:49195 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8xJB-0008RE-Vt for ged-emacs-devel@m.gmane.org; Fri, 13 Nov 2009 09:39:30 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N8xJ6-0008Qj-O8 for emacs-devel@gnu.org; Fri, 13 Nov 2009 09:39:24 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N8xJ2-0008Q5-Cj for emacs-devel@gnu.org; Fri, 13 Nov 2009 09:39:24 -0500 Original-Received: from [199.232.76.173] (port=59881 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8xJ2-0008Pt-3G for emacs-devel@gnu.org; Fri, 13 Nov 2009 09:39:20 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:4776 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N8xJ1-0004IA-Qg for emacs-devel@gnu.org; Fri, 13 Nov 2009 09:39:19 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEANr9/EpFpYg5/2dsb2JhbACBTdQuhDwEiTSCeQ X-IronPort-AV: E=Sophos;i="4.44,737,1249272000"; d="scan'208";a="49352483" Original-Received: from 69-165-136-57.dsl.teksavvy.com (HELO pastel.home) ([69.165.136.57]) by ironport2-out.pppoe.ca with ESMTP; 13 Nov 2009 09:39:19 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 1A1B67F82; Fri, 13 Nov 2009 09:39:19 -0500 (EST) In-Reply-To: <200911130524.nAD5O5uu009102@godzilla.ics.uci.edu> (Dan Nicolaescu's message of "Thu, 12 Nov 2009 21:24:05 -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:116947 Archived-At: >> Actually, it's even worse than that: (interned) symbols have a `next' >> field which points to the next symbol in the obarray (hash) bucket. >> So that's yet another reason why (pure)symbols can have pointers to non >> pure memory. > Can't the next pointers could be NULL. Of course: the last symbol in a bucket has a NULL there (as do non-interned symbols). Can't see why that would make a difference, tho. > Is the next pointer used for anything else other than GC? Yes, of course: it's used for the hash-lookup done in `intern' (and `intern-soft'). > Because if it's not, then it seems that if the next pointer was stored > in the obarray the cache footprint of a Lisp_Symbol would be smaller. You can remove the `next' pointer to make symbols smaller (tho on 32bit machines it would only make them smaller if you additionally remove another field (like plist), because of the alignment constraint). But then you need to link all interned symbols via an (external) list, and since most symbols are interned (AFAIK), that would end up adding more memory than is saved. Admittedly, it could still result in a smaller cache footprint. It's just far from obvious that there's much to gain here. I still strongly believe there's more to be gained by optimizing the tight mark_object (recursive) loop than by trying to squeeze a few more bytes into the purespace: once your Emacs session grows sufficiently large, the saving of not tracing through the purespace becomes negligible. Stefan