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: Sun, 15 Nov 2009 20:34:19 -0500 Message-ID: References: <200911112023.nABKNrH6023933@godzilla.ics.uci.edu> <87pr7oxieq.fsf@freebits.de> <200911130524.nAD5O5uu009102@godzilla.ics.uci.edu> <200911152108.nAFL8IBl006966@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 1258335281 20199 80.91.229.12 (16 Nov 2009 01:34:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Nov 2009 01:34:41 +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 Mon Nov 16 02:34:34 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 1N9qUE-0001XN-BD for ged-emacs-devel@m.gmane.org; Mon, 16 Nov 2009 02:34:34 +0100 Original-Received: from localhost ([127.0.0.1]:48970 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N9qUD-0003fT-NN for ged-emacs-devel@m.gmane.org; Sun, 15 Nov 2009 20:34:33 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N9qU8-0003f8-AK for emacs-devel@gnu.org; Sun, 15 Nov 2009 20:34:28 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N9qU2-0003eC-RK for emacs-devel@gnu.org; Sun, 15 Nov 2009 20:34:27 -0500 Original-Received: from [199.232.76.173] (port=39691 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N9qU2-0003e8-OA for emacs-devel@gnu.org; Sun, 15 Nov 2009 20:34:22 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:10974 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N9qU1-0007CQ-PI for emacs-devel@gnu.org; Sun, 15 Nov 2009 20:34:22 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwEAF46AEtMCqHJ/2dsb2JhbACBTdEUhDwEiT6Ceg X-IronPort-AV: E=Sophos;i="4.44,748,1249272000"; d="scan'208";a="49453548" Original-Received: from 76-10-161-201.dsl.teksavvy.com (HELO pastel.home) ([76.10.161.201]) by ironport2-out.pppoe.ca with ESMTP; 15 Nov 2009 20:34:20 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 6C4688154; Sun, 15 Nov 2009 20:34:19 -0500 (EST) In-Reply-To: <200911152108.nAFL8IBl006966@godzilla.ics.uci.edu> (Dan Nicolaescu's message of "Sun, 15 Nov 2009 13:08:18 -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:117026 Archived-At: > #define MAYBE_MARK_OBJECT(ARG) \ > do { \ > Lisp_Object OBJ = ARG; \ > \ > if ((XTYPE (OBJ) == Lisp_Symbol)) \ Please don't use this. Always use SYMBOLP instead. > { \ > struct Lisp_Symbol *tptr = XSYMBOL (OBJ); \ > if (!tptr->gcmarkbit) \ > mark_object (OBJ); \ > } \ > else \ > mark_object (OBJ); \ > } while (0) This may save a few function calls for some symbols, but adds a test for all other cases, so it's unlikely to win much if anything. I think some of the needed changes to streamline the code would be to remove the PUREP test (i.e. just always keep the mark bit set on pure objects instead. This will require changing the way we handle the markbit on strings and vectors). Maybe we'd also want to unify the code that extracts the markbit for the various possible objects, so that we can check the markbit before we dispatch on the type of object we're looking at. That would be an even more drastic change. > The big problem in GC is the trashing of the memory system due to > setting/resetting and reading the mark bits... Could be as well. In that case, maybe we should move all the markbits to separate bitvectors like we have for cons and floats. Stefan