From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.devel Subject: Re: t and nil in pure memory? Date: Thu, 12 Nov 2009 21:24:05 -0800 (PST) Message-ID: <200911130524.nAD5O5uu009102@godzilla.ics.uci.edu> References: <200911112023.nABKNrH6023933@godzilla.ics.uci.edu> <87pr7oxieq.fsf@freebits.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1258090007 8385 80.91.229.12 (13 Nov 2009 05:26:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Nov 2009 05:26:47 +0000 (UTC) Cc: "Tobias C. Rittweiler" , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 13 06:26:40 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 1N8ogC-0000EZ-9A for ged-emacs-devel@m.gmane.org; Fri, 13 Nov 2009 06:26:40 +0100 Original-Received: from localhost ([127.0.0.1]:33705 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8ogB-0002zz-Oz for ged-emacs-devel@m.gmane.org; Fri, 13 Nov 2009 00:26:39 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N8ofv-0002qB-K3 for emacs-devel@gnu.org; Fri, 13 Nov 2009 00:26:23 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N8ofq-0002lO-TH for emacs-devel@gnu.org; Fri, 13 Nov 2009 00:26:23 -0500 Original-Received: from [199.232.76.173] (port=34495 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8ofq-0002lD-J5 for emacs-devel@gnu.org; Fri, 13 Nov 2009 00:26:18 -0500 Original-Received: from paul-mcgann-v0.ics.uci.edu ([128.195.1.147]:37382) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N8ofq-000329-4Q for emacs-devel@gnu.org; Fri, 13 Nov 2009 00:26:18 -0500 Original-Received: from godzilla.ics.uci.edu (godzilla.ics.uci.edu [128.195.10.101]) by paul-mcgann-v0.ics.uci.edu (8.13.8/8.13.8) with ESMTP id nAD5O5CT026786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Nov 2009 21:24:05 -0800 Original-Received: (from dann@localhost) by godzilla.ics.uci.edu (8.13.8+Sun/8.13.6/Submit) id nAD5O5uu009102; Thu, 12 Nov 2009 21:24:05 -0800 (PST) In-Reply-To: (Stefan Monnier's message of "Thu, 12 Nov 2009 10:22:05 -0500") Original-Lines: 25 X-ICS-MailScanner-Information: Please send mail to helpdesk@ics.uci.edu or more information X-ICS-MailScanner-ID: nAD5O5CT026786 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.44, required 5, autolearn=disabled, ALL_TRUSTED -1.44) X-ICS-MailScanner-From: dann@godzilla.ics.uci.edu 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:116927 Archived-At: Stefan Monnier writes: > >> > 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). > > > In principle, you could scratch the plist slot from symbols themselves, > > and instead make `symbol-plist' go over an EQ hash-table. (Such > > externalizing of the symbol plist may make more sense in other dialects > > of Lisp where the plist is used less often than in Elisp -- even though > > I'm not aware of any implementation which does.) > > 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. Is the next pointer used for anything else other than GC? 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.