From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: GC: cons sweeping and cons block size Date: Fri, 6 Jul 2007 07:54:46 -0400 Message-ID: References: <468B4194.000005.15879@pantene.yandex.ru> <86644ylxo2.fsf@lola.quinscape.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1183722953 18977 80.91.229.12 (6 Jul 2007 11:55:53 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 6 Jul 2007 11:55:53 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 06 13:55:49 2007 connect(): Connection refused 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 1I6mPX-0000dj-It for ged-emacs-devel@m.gmane.org; Fri, 06 Jul 2007 13:55:43 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I6mPW-0003xG-EP for ged-emacs-devel@m.gmane.org; Fri, 06 Jul 2007 07:55:42 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I6mPS-0003w4-IF for emacs-devel@gnu.org; Fri, 06 Jul 2007 07:55:38 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I6mPN-0003r2-L7 for emacs-devel@gnu.org; Fri, 06 Jul 2007 07:55:37 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I6mPN-0003qh-Fm for emacs-devel@gnu.org; Fri, 06 Jul 2007 07:55:33 -0400 Original-Received: from alnrmhc16.comcast.net ([204.127.225.96]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1I6mPN-000099-4p for emacs-devel@gnu.org; Fri, 06 Jul 2007 07:55:33 -0400 Original-Received: from raeburn.org (c-65-96-188-63.hsd1.ma.comcast.net[65.96.188.63]) by comcast.net (alnrmhc16) with ESMTP id <20070706115450b16006k3s7e>; Fri, 6 Jul 2007 11:54:51 +0000 Original-Received: from [69.25.196.100] (fwoosh.raeburn.org [69.25.196.100]) by raeburn.org (8.12.11/8.12.11) with ESMTP id l66BsnJY022571; Fri, 6 Jul 2007 07:54:49 -0400 (EDT) In-Reply-To: X-Mailer: Apple Mail (2.752.2) X-detected-kernel: Solaris 10 (1203?) 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:74389 Archived-At: On Jul 5, 2007, at 12:02, Stefan Monnier wrote: (quoting David, who was quoting Stefan) >>> I haven't found the time to do it, but it would be good to get >>> rid of this >>> situation and always place tags in the 3 LSB bits. It does appear to be the default for most systems, maybe all modern ones, but only when we compile with GCC. Are we confident no one is using Emacs on systems where we use a system malloc that doesn't do 8- byte alignment? Or where the native compiler doesn't do 8-byte alignment for static objects? I think I'd be happier with changing the default to use USE_LSB_TAG always but check the malloc return values and compiler-produced alignment on the configurations where we don't already know we're safe, and perhaps delete that code and maybe much of the non-USE_LSB_TAG code a while after it's released without related bug reports; I'm afraid that temporarily increases the ugliness rather than reducing it though. > Luckily, YAILOM problems can be cought by the compiler if you > use -DUSE_LISP_UNION_TYPE (but it incurs a performance hit, which > is why > it's not used by default). Hm, I don't think I ever got around to seeing if __attribute__ ((transparent_union)) would fix the performance... We could do a USE_LSB_TAG variant of the union, to get more address space back but keep the paranoid type checking capability. Ken