conservative stack scanning (was: Re: bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2)

conservative stack scanning (was: Re: bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2)

[Stefan Monnier]

> No, GCC consistently refused to compile it.  It's just that
> this code is rarely compiled -- it's normally ifdeffed out,
> so GCC doesn't see the problem.  I suppose that on AIX the
> code is not ifdeffed out, so that's why the bug was reported
> for AIX.

Ah, that's where the AIX-dependence comes from!
Shouldn't we just enable conservative stack scanning for
all architectures?  AFAIK, the only systems where we don't use it are
systems where we don't know whether we can use it, rather than systems
where we know we can't use it.


        Stefan

Re: conservative stack scanning

[Paul Eggert]

On 01/11/2013 11:51 AM, Stefan Monnier wrote:
> Shouldn't we just enable conservative stack scanning for
> all architectures?

Yes, we should give it a try.  If it doesn't work we can revert.
If it does work, we can simplify Emacs and this will help prevent
future bugs like Bug#13408.

Here's a proposed patch.

=== modified file 'ChangeLog'
--- ChangeLog	2013-01-11 23:28:04 +0000
+++ ChangeLog	2013-01-12 01:49:51 +0000
@@ -1,3 +1,10 @@
+2013-01-12  Paul Eggert  <eggert@cs.ucla.edu>
+
+	Enable conservative stack scanning for all architectures.
+	Suggested by Stefan Monnier in
+	<http://lists.gnu.org/archive/html/emacs-devel/2013-01/msg00183.html>.
+	* configure.ac (GC_MARK_STACK): Remove.
+
 2013-01-11  Paul Eggert  <eggert@cs.ucla.edu>
 
 	* lib/getopt_.h: Remove trailing CRs that crept in.

=== modified file 'configure.ac'
--- configure.ac	2013-01-10 03:43:02 +0000
+++ configure.ac	2013-01-12 01:49:51 +0000
@@ -3777,22 +3777,13 @@
 esac
 
 
-dnl These won't be used automatically yet.  We also need to know, at least,
+dnl This won't be used automatically yet.  We also need to know, at least,
 dnl that the stack is continuous.
 AH_TEMPLATE(GC_SETJMP_WORKS, [Define if setjmp is known to save all
   registers relevant for conservative garbage collection in the jmp_buf.])
 
-AH_TEMPLATE(GC_MARK_STACK, [Define to GC_USE_GCPROS_AS_BEFORE if
-  conservative garbage collection is not known to work.])
-
 
 case $opsys in
-  aix4-2 | hpux* | unixware)
-    dnl Conservative garbage collection has not been tested, so for now
-    dnl play it safe and stick with the old-fashioned way of marking.
-    AC_DEFINE(GC_MARK_STACK, [GC_USE_GCPROS_AS_BEFORE])
-    ;;
-
   dnl Not all the architectures are tested, but there are Debian packages
   dnl for SCM and/or Guile on them, so the technique must work.  See also
   dnl comments in alloc.c concerning setjmp and gcc.
@@ -3807,8 +3798,7 @@
 #else
 # error "setjmp not known to work on this arch"
 #endif
-    ]], [[]])], AC_DEFINE(GC_SETJMP_WORKS, 1),
-      AC_DEFINE(GC_MARK_STACK, [GC_USE_GCPROS_AS_BEFORE]) )
+    ]], [[]])], AC_DEFINE(GC_SETJMP_WORKS, 1))
     ;;
 esac
 

=== modified file 'src/lisp.h'
--- src/lisp.h	2013-01-11 13:25:10 +0000
+++ src/lisp.h	2013-01-12 01:49:51 +0000
@@ -2217,7 +2217,14 @@
    2    Mark the stack, and check that everything GCPRO'd is
 	marked.
    3	Mark using GCPRO's, mark stack last, and count how many
-	dead objects are kept alive.  */
+	dead objects are kept alive.
+
+   Formerly, method 0 was used.  Currently, method 1 is used unless
+   specified by hand when building, e.g.,
+   "make CPPFLAGS='-DGC_MARK_STACK=GC_USE_GCPROS_AS_BEFORE'".
+   Methods 2 and 3 are present mainly to debug the transition from 0 to 1.
+   At some point we should simplify Emacs by removing support
+   for all methods other than method 1.  */
 
 
 #define GC_USE_GCPROS_AS_BEFORE		0

Broken !GC_MARK_STACK [Re: conservative stack scanning]

[Dmitry Antipov]

On 01/12/2013 05:51 AM, Paul Eggert wrote:

> On 01/11/2013 11:51 AM, Stefan Monnier wrote:
>> Shouldn't we just enable conservative stack scanning for
>> all architectures?
>
> Yes, we should give it a try.  If it doesn't work we can revert.
> If it does work, we can simplify Emacs and this will help prevent
> future bugs like Bug#13408.

Argh, current trunk is broken with !GC_MARK_STACK anyway:

1) I don't know why this isn't in the trunk:
    http://lists.gnu.org/archive/html/emacs-devel/2011-11/txtjY_VzSBijo.txt

2) My stuff from commit 111073 breaks !GC_MARK_STACK because Lisp_Objects
    referenced from Lisp_Misc_Save_Value are marked only if GC_MARK_STACK :-(.

Dmitry

Re: conservative stack scanning

[Stefan Monnier]

> Yes, we should give it a try.  If it doesn't work we can revert.
> If it does work, we can simplify Emacs and this will help prevent
> future bugs like Bug#13408.
> Here's a proposed patch.

Looks OK.

> +   At some point we should simplify Emacs by removing support
> +   for all methods other than method 1.  */

There's no point including such speculation in there.


        Stefan

Re: conservative stack scanning

[Paul Eggert]

On 01/11/2013 08:23 PM, Stefan Monnier wrote:
> There's no point including such speculation in there.

OK, thanks, I removed the speculation and installed
that into the trunk as bzr 111496.

Re: Broken !GC_MARK_STACK [Re: conservative stack scanning]

[Paul Eggert]

On 01/11/2013 06:15 PM, Dmitry Antipov wrote:

> Argh, current trunk is broken with !GC_MARK_STACK anyway:
> 
> 1) I don't know why this isn't in the trunk:
>    http://lists.gnu.org/archive/html/emacs-devel/2011-11/txtjY_VzSBijo.txt

I just now pushed that into the trunk, 
as bzr 111497.

> 2) My stuff from commit 111073 breaks !GC_MARK_STACK because Lisp_Objects
>    referenced from Lisp_Misc_Save_Value are marked only if GC_MARK_STACK :-(.

Is that something you can fix easily?

Re: Broken !GC_MARK_STACK [Re: conservative stack scanning]

[Dmitry Antipov]

On 01/12/2013 10:19 AM, Paul Eggert wrote:

> On 01/11/2013 06:15 PM, Dmitry Antipov wrote:
>
>> 1) I don't know why this isn't in the trunk:
>>     http://lists.gnu.org/archive/html/emacs-devel/2011-11/txtjY_VzSBijo.txt
>
> I just now pushed that into the trunk,
> as bzr 111497.

OK, thanks.

>
>> 2) My stuff from commit 111073 breaks !GC_MARK_STACK because Lisp_Objects
>>     referenced from Lisp_Misc_Save_Value are marked only if GC_MARK_STACK :-(.
>
> Is that something you can fix easily?

Hm... not so easy, but this is bzr 111518.

Dmitry