From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r107377: * src/lisp.h: Improve comment about USE_LSB_TAG. Date: Fri, 24 Feb 2012 23:00:39 -0800 Organization: UCLA Computer Science Department Message-ID: <4F488717.2060108@cs.ucla.edu> References: <4F459455.8070206@verizon.net> <4F45DD5B.3010801@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1330153269 28763 80.91.229.3 (25 Feb 2012 07:01:09 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 25 Feb 2012 07:01:09 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 25 08:01:08 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 1S1Bcw-0005R0-Cg for ged-emacs-devel@m.gmane.org; Sat, 25 Feb 2012 08:01:06 +0100 Original-Received: from localhost ([::1]:33529 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S1Bcv-0005Ri-CI for ged-emacs-devel@m.gmane.org; Sat, 25 Feb 2012 02:01:05 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:52810) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S1Bcm-0005QV-Py for emacs-devel@gnu.org; Sat, 25 Feb 2012 02:01:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S1Bcg-0001cP-QQ for emacs-devel@gnu.org; Sat, 25 Feb 2012 02:00:56 -0500 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:45391) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S1Bcg-0001bv-HG for emacs-devel@gnu.org; Sat, 25 Feb 2012 02:00:50 -0500 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 21AA4A60002; Fri, 24 Feb 2012 23:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uamnwxOZxGF; Fri, 24 Feb 2012 23:00:46 -0800 (PST) Original-Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id E454B39E800B; Fri, 24 Feb 2012 23:00:37 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 131.179.128.62 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:148772 Archived-At: On 02/22/2012 11:42 PM, Stefan Monnier wrote: > What I suggest is just to take the O(N) pointer-sized entities on > the stack, cast them to EMACS_INT, and pass them to > mark_maybe_object. Thanks, I see now. Something like the following, then. Yes, that does simplify things. Generalize fix for crash due to non-contiguous EMACS_INT (Bug#10780). Suggested by Stefan Monnier in . * alloc.c (widen_to_Lisp_Object): New static function. (POINTERS_MIGHT_HIDE_IN_OBJECTS): New macro. (mark_memory): Mark Lisp_Objects by fetching pointer words and widening them to Lisp_Objects. This works better with wide integers, and works even if USE_USB_TAG is not defined. Mark Lisp_Objects only if pointers might hide in objects, as mark_maybe_pointer will catch them otherwise. (GC_LISP_OBJECT_ALIGNMENT): Remove; no longer needed. * s/gnu-linux.h (GC_LISP_OBJECT_ALIGNMENT) [__mc68000__]: Likewise. === modified file 'src/alloc.c' --- src/alloc.c 2012-02-10 18:58:48 +0000 +++ src/alloc.c 2012-02-25 06:48:29 +0000 @@ -1582,6 +1582,21 @@ } #endif +/* Convert the pointer-sized word P to EMACS_INT while preserving its + type and ptr fields. */ +static Lisp_Object +widen_to_Lisp_Object (void *p) +{ + intptr_t i = (intptr_t) p; +#ifdef USE_LISP_UNION_TYPE + Lisp_Object obj; + obj.i = i; + return obj; +#else + return i; +#endif +} + /*********************************************************************** String Allocation ***********************************************************************/ @@ -4236,23 +4251,35 @@ } -/* Alignment of Lisp_Object and pointer values. Use offsetof, as it - sometimes returns a smaller alignment than GCC's __alignof__ and - mark_memory might miss objects if __alignof__ were used. For - example, on x86 with WIDE_EMACS_INT, __alignof__ (Lisp_Object) is 8 - but GC_LISP_OBJECT_ALIGNMENT should be 4. */ -#ifndef GC_LISP_OBJECT_ALIGNMENT -# define GC_LISP_OBJECT_ALIGNMENT offsetof (struct {char a; Lisp_Object b;}, b) -#endif +/* Alignment of pointer values. Use offsetof, as it sometimes returns + a smaller alignment than GCC's __alignof__ and mark_memory might + miss objects if __alignof__ were used. */ #define GC_POINTER_ALIGNMENT offsetof (struct {char a; void *b;}, b) +/* Define POINTERS_MIGHT_HIDE_IN_OBJECTS to 1 if marking via C pointers does + not suffice, which is the typical case. */ +#if defined USE_LSB_TAG || UINTPTR_MAX >> VALBITS != 0 +# if !defined USE_LSB_TAG && UINTPTR_MAX >> VALBITS >> GCTYPEBITS != 0 + /* If tag bits straddle pointer-word boundaries, neither mark_maybe_pointer + nor mark_maybe_object can follow the pointers. This should not occur on + any practical porting target. */ +# error "MSB type bits straddle pointer-word boundaries" +# endif + /* Marking via C pointers does not suffice, because Lisp_Objects contain + pointer words that hold pointers ORed with type bits. */ +# define POINTERS_MIGHT_HIDE_IN_OBJECTS 1 +#else + /* Marking via C pointers suffices, because Lisp_Objects contain pointer + words that hold unmodified pointers. */ +# define POINTERS_MIGHT_HIDE_IN_OBJECTS 0 +#endif + /* Mark Lisp objects referenced from the address range START+OFFSET..END or END+OFFSET..START. */ static void mark_memory (void *start, void *end) { - Lisp_Object *p; void **pp; int i; @@ -4269,11 +4296,6 @@ end = tem; } - /* 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)); - /* Mark Lisp data pointed to. This is necessary because, in some situations, the C compiler optimizes Lisp objects away, so that only a pointer to them remains. Example: @@ -4294,7 +4316,12 @@ for (pp = start; (void *) pp < end; pp++) for (i = 0; i < sizeof *pp; i += GC_POINTER_ALIGNMENT) - mark_maybe_pointer (*(void **) ((char *) pp + i)); + { + void *p = *(void **) ((char *) pp + i); + mark_maybe_pointer (p); + if (POINTERS_MIGHT_HIDE_IN_OBJECTS) + mark_maybe_object (widen_to_Lisp_Object (p)); + } } /* setjmp will work with GCC unless NON_SAVING_SETJMP is defined in === modified file 'src/s/gnu-linux.h' --- src/s/gnu-linux.h 2012-01-19 07:21:25 +0000 +++ src/s/gnu-linux.h 2012-02-25 06:48:29 +0000 @@ -146,9 +146,6 @@ || defined __ia64__ || defined __sh__ #define GC_SETJMP_WORKS 1 #define GC_MARK_STACK GC_MAKE_GCPROS_NOOPS -#ifdef __mc68000__ -#define GC_LISP_OBJECT_ALIGNMENT 2 -#endif #ifdef __ia64__ #define GC_MARK_SECONDARY_STACK() \ do { \