From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: t and nil in pure memory? Date: Sat, 14 Nov 2009 06:23:09 -0500 Message-ID: References: <200911112023.nABKNrH6023933@godzilla.ics.uci.edu> <87pr7oxieq.fsf@freebits.de> <200911130524.nAD5O5uu009102@godzilla.ics.uci.edu> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: ger.gmane.org 1258197813 829 80.91.229.12 (14 Nov 2009 11:23:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Nov 2009 11:23:33 +0000 (UTC) Cc: tcr@freebits.de, dann@ics.uci.edu, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 14 12:23:26 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 1N9Giz-00026p-9e for ged-emacs-devel@m.gmane.org; Sat, 14 Nov 2009 12:23:25 +0100 Original-Received: from localhost ([127.0.0.1]:52273 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N9Giy-0006fQ-Jf for ged-emacs-devel@m.gmane.org; Sat, 14 Nov 2009 06:23:24 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N9Gip-0006f5-FJ for emacs-devel@gnu.org; Sat, 14 Nov 2009 06:23:15 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N9Gik-0006cg-Be for emacs-devel@gnu.org; Sat, 14 Nov 2009 06:23:14 -0500 Original-Received: from [199.232.76.173] (port=57653 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N9Gik-0006cR-1l for emacs-devel@gnu.org; Sat, 14 Nov 2009 06:23:10 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:58244) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N9Gij-0006su-Q0 for emacs-devel@gnu.org; Sat, 14 Nov 2009 06:23:09 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1N9Gij-0003Cx-13; Sat, 14 Nov 2009 06:23:09 -0500 In-reply-to: (message from Stefan Monnier on Fri, 13 Nov 2009 09:39:19 -0500) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:116973 Archived-At: You can remove the `next' pointer to make symbols smaller (tho on 32bit machines Do you mean 64-bit machines? it would only make them smaller if you additionally remove another field (like plist), because of the alignment constraint). That's because of 5 bits. If we could get rid of them, or move them somewhere, we could reduce the size by 64 bits. One way to avoid the next pointer is by storing all the symbol pointers directly in the obarray, and making the obarray larger when it gets close to full. That's not traditional for Lisp obarrays but it might be ok. That would replace N words in symbols with maybe n*1.3 words in the obarray. Then all that is needed is to move those 5 bits somewhere, perhaps packing them into the pointers in a symbol in some kludgy way. Anyway, it is easy to store the plists for t and nil in a couple of C variables, without changing the format of symbols. This requires a little special code in the plist access functions, but maybe the time that costs will be less than what is saved in GC. As for their next pointers, if they are the first symbols to be interned, they are at the end of their obarray buckets, so their next pointers never need to be changed. (We should make `unintern' check for t and nil and give an error.)