From: Paul Eggert <eggert@cs.ucla.edu>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
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 [thread overview]
Message-ID: <4F488717.2060108@cs.ucla.edu> (raw)
In-Reply-To: <jwvehtmuhwb.fsf-monnier+emacs@gnu.org>
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
<http://lists.gnu.org/archive/html/emacs-devel/2012-02/msg00638.html>.
* 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
\f
+/* 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
+}
+\f
/***********************************************************************
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 { \
next prev parent reply other threads:[~2012-02-25 7:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1S0EsZ-0006bE-5w@vcs.savannah.gnu.org>
2012-02-22 20:25 ` [Emacs-diffs] /srv/bzr/emacs/trunk r107377: * src/lisp.h: Improve comment about USE_LSB_TAG Stefan Monnier
2012-02-23 1:20 ` Paul Eggert
2012-02-23 3:15 ` Stefan Monnier
2012-02-23 6:31 ` Paul Eggert
2012-02-23 7:42 ` Stefan Monnier
2012-02-25 7:00 ` Paul Eggert [this message]
2012-02-25 10:06 ` Stefan Monnier
2012-02-25 19:46 ` Paul Eggert
2012-02-23 3:57 ` YAMAMOTO Mitsuharu
2012-02-23 6:28 ` Paul Eggert
2012-05-09 17:56 ` Paul Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F488717.2060108@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).