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: GC: cons sweeping and cons block size Date: Thu, 05 Jul 2007 12:02:37 -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 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1183651637 6492 80.91.229.12 (5 Jul 2007 16:07:17 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 5 Jul 2007 16:07:17 +0000 (UTC) Cc: jyavner@member.fsf.org, dmantipov@yandex.ru, emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 05 18:07:15 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 1I6TrO-0001tI-9A for ged-emacs-devel@m.gmane.org; Thu, 05 Jul 2007 18:07:14 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I6TrN-0003dS-SZ for ged-emacs-devel@m.gmane.org; Thu, 05 Jul 2007 12:07:13 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I6Tn7-0000UK-Od for emacs-devel@gnu.org; Thu, 05 Jul 2007 12:02:49 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I6Tn6-0000T6-4q for emacs-devel@gnu.org; Thu, 05 Jul 2007 12:02:49 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I6Tn5-0000St-NX for emacs-devel@gnu.org; Thu, 05 Jul 2007 12:02:47 -0400 Original-Received: from mercure.iro.umontreal.ca ([132.204.24.67]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1I6Tn2-0005uR-DU; Thu, 05 Jul 2007 12:02:44 -0400 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 9DCEF2CF029; Thu, 5 Jul 2007 12:02:41 -0400 (EDT) Original-Received: from faina.iro.umontreal.ca (faina.iro.umontreal.ca [132.204.26.177]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 8107D3FE0; Thu, 5 Jul 2007 12:02:37 -0400 (EDT) Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 6CEF36C8CC; Thu, 5 Jul 2007 12:02:37 -0400 (EDT) In-Reply-To: <86644ylxo2.fsf@lola.quinscape.zz> (David Kastrup's message of "Thu\, 05 Jul 2007 16\:42\:21 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-detected-kernel: 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:74348 Archived-At: >>> On some systems, Lisp_Object may be a tagged pointer with 29-bit (on >>> 32-bit system) pointer field. Since mmap() tends to allocate memory at >>> high addresses, this memory is likely to be non-addressable by such >>> pointer. That is why lisp_align_malloc() currently uses >>> mallopt(M_MMAP_MAX, 0) to prevent mapping the region (if underlying >>> malloc() supports this). >> >> 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. > Would that impact the severity of YAILM (or what the integer/lisp > mixups were called) occurences? Not at all. Actually the severity of YAILOM is increased with the use of LSB bits for tags: since the 000 tag has traditionally been used for integers, it means that positive integers were represented by themselves (when placing tags in the MSB), so YAILOM errors would often cause no problem in practice, whereas when placing tags in the LSB all integers need shifting, so YAILOM errors lead to lack of those shifts which leads to integers being "tagged" randomly (depending on their value mod 8), often causing Emacs to treat those integers as pointers which then cause segmentation violations. 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). Stefan