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: [Emacs-diffs] /srv/bzr/emacs/trunk r107377: * src/lisp.h: Improve comment about USE_LSB_TAG. Date: Wed, 22 Feb 2012 22:15:40 -0500 Message-ID: References: <4F459455.8070206@verizon.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1329966979 28605 80.91.229.3 (23 Feb 2012 03:16:19 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 23 Feb 2012 03:16:19 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 23 04:16:18 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1S0PAD-0002FB-Ap for ged-emacs-devel@m.gmane.org; Thu, 23 Feb 2012 04:16:13 +0100 Original-Received: from localhost ([::1]:48064 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S0PAC-0004dP-18 for ged-emacs-devel@m.gmane.org; Wed, 22 Feb 2012 22:16:12 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:59854) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S0PA8-0004d6-8e for emacs-devel@gnu.org; Wed, 22 Feb 2012 22:16:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S0PA7-0006v6-6C for emacs-devel@gnu.org; Wed, 22 Feb 2012 22:16:08 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:40653) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S0PA7-0006uu-2o for emacs-devel@gnu.org; Wed, 22 Feb 2012 22:16:07 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADqvRU9Ld/XJ/2dsb2JhbABEsliBCIFzAQEEAVYjBQsLNBIUGA0kiBS4TY0KIEEXBggChRcKhBsEiE+WI4R2hFs X-IronPort-AV: E=Sophos;i="4.73,467,1325480400"; d="scan'208";a="164249717" Original-Received: from 75-119-245-201.dsl.teksavvy.com (HELO pastel.home) ([75.119.245.201]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 22 Feb 2012 22:15:40 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 456F359173; Wed, 22 Feb 2012 22:15:40 -0500 (EST) In-Reply-To: <4F459455.8070206@verizon.net> (Paul Eggert's message of "Wed, 22 Feb 2012 17:20:21 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.93 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.183 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:148715 Archived-At: >> What kind of extra masking are you referring to? The XFASTINT? >> Note that the LSB masking can be cheaper than the MSB masking > No, it's XPNTR that's faster, because its masking comes for free -- > zero runtime overhead on my platform. Oh, interesting. The masking code is not null, but the compiler manages to compile it away because it masks bits that are outside the range of pointers. >> So "VALBITS is greater than the pointer width in bits" is not >> the exactly right condition (e.g. if we have 48bit pointers and 61 >> VALBITS then the problem should not appear). > Most likely not, true. The current code is conservative. I don't > know of any real platform where the conservatism matters, though. No, indeed it doesn't matter in practical terms, it only matters if you try to understand what's really going on. >> Maybe a better fix is to add code to the stack marking loop, conditional >> on WIDE_EMACS_INT and USE_LSB_TAGS, which passes pointer-sized >> words to mark_maybe_object after expanding them to EMACS_INT size. > That patch would be more intrusive. Arguably, yes, but it would have the advantage to attack more precisely the actual core of the problem, so it "reifies" in the code our deeper understanding of the problem. IOW it makes it less likely that someone later on won't understand what's going on. > Plus, the following (further) patch is simpler and faster. This patch > is purely a performance improvement so I didn't install it (was > planning to do it after 24.1 comes out, but if you like I can do it > now....). > +#if defined USE_LSB_TAG || UINTPTR_MAX >> VALBITS != 0 > /* Mark Lisp_Objects. */ > for (p = start; (void *) p < end; p++) > for (i = 0; i < sizeof *p; i += GC_LISP_OBJECT_ALIGNMENT) > mark_maybe_object (*(Lisp_Object *) ((char *) p + i)); > +#endif I'm not sure why you think this patch is "simpler and faster", since AFAICT it does not solve the original problem, whereas the change I suggested does (or at least, should), so they're basically incomparable. As for that change, the reasoning for why it's correct doesn't seem obvious to me (I understand why it's correct in the current WIDE_EMACS_INT case, but generalizing from that to the case "UINTPTR_MAX >> VALBITS != 0" seems risky). So I'm not in favor of this optimization as it is (of course not for 24.1, but probably not for 24.2 either). Stefan