unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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 {								\





  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).