GNU bug report logs -
#36649
27.0.50; pure space and pdumper
Previous Next
Reported by: Pip Cet <pipcet <at> gmail.com>
Date: Sun, 14 Jul 2019 14:27:01 UTC
Severity: wishlist
Tags: patch
Found in version 27.0.50
Done: Pip Cet <pipcet <at> protonmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36649 in the body.
You can then email your comments to 36649 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sun, 14 Jul 2019 14:27:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Pip Cet <pipcet <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sun, 14 Jul 2019 14:27:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
This is a follow-up to bug #36447, which has been fixed and closed.
Currently, pure space is wasted when using pdumper, and CHECK_IMPURE
does nothing at run time.
The current situation when using pdumper is this:
- pure space is put into the initial emacs executable as an all-zero
area with a single 1 in it, which is used to prevent the area being
placed into BSS
- before dump, data is placed into the pure space by purecopy
- before dump, PURE_P returns true for pure data, and CHECK_IMPURE
dies for pure arguments
- when dumping, pure data is indiscriminately mixed with impure data
and placed in the pdumper file without special treatment of any kind
- when launching the real emacs, pure space is also initialized from
the executable, as an all-zero area
- all data from the pdumper file is restored to heap memory, without
distinguishing formerly-pure data from formerly-impure data
- PURE_P is never called with a pure space pointer, it essentially
always returns false
- CHECK_IMPURE does nothing except waste a few cycles
That situation is unsatisfactory. We fail to catch modification of
formerly-pure data after loading the dump, and we waste several
megabytes of executable image size on zeroed data.
I think we have the following options:
1. remove pure space entirely
2. remove pure space, but leave PURE_P and CHECK_IMPURE as reminders
to do something about it.
3. move pure space to BSS
4. xmalloc() pure space, only when needed
5. modify pdumper to mark and recognize pure objects
6. do nothing and accept the wastefulness
I prefer (2), for this reason:
CHECK_IMPURE is useful, and should be extended to something like
CHECK_MUTABLE, which checks for objects including:
1. pure data
2. data read with `read'
3. data explicitly marked as immutable
(That would mean code like
(defconst list-a (nconc '(a b c) list-b))
would cease to be valid, and that's one of the problems I'm running
into with code I'm playing around with.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sun, 21 Jul 2019 07:29:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> I think we have the following options:
>
> 1. remove pure space entirely
> 2. remove pure space, but leave PURE_P and CHECK_IMPURE as reminders
> to do something about it.
> 3. move pure space to BSS
> 4. xmalloc() pure space, only when needed
> 5. modify pdumper to mark and recognize pure objects
> 6. do nothing and accept the wastefulness
I suggest (1), since it will result in simpler code. Although (2) would be OK
too, if we ever introduce immutable objects it's likely that PURE_P and/or
CHECK_IMPURE will just get in the way anyway. We can see a hint of that in my
patch today that added temporary immutability to hash tables to fix a core-dump bug.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sun, 21 Jul 2019 12:55:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 36649 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Jul 21, 2019 at 7:29 AM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> > I think we have the following options:
> >
> > 1. remove pure space entirely
> > 2. remove pure space, but leave PURE_P and CHECK_IMPURE as reminders
> > to do something about it.
> > 3. move pure space to BSS
> > 4. xmalloc() pure space, only when needed
> > 5. modify pdumper to mark and recognize pure objects
> > 6. do nothing and accept the wastefulness
>
> I suggest (1), since it will result in simpler code.
I think we should do (1) for now, since it simplifies the code enough
to introduce immutable objects "soon"; but until that time, we waste
more space on duplicate objects that we no longer know to be
immutable, so cannot merge.
I'm attaching a first patch that removes pure space, pinned symbols,
pinned objects, but keeps Fpurecopy (for hash consing), and doesn't
touch the Lisp codebase.
With this patch, I have:
-rw-r--r-- 2 pip pip 11102752 Jul 21 12:28 src/emacs.pdmp
before:
-rw-r--r-- 2 pip pip 10381464 Jul 21 12:29 src/emacs.pdmp
However, the (uncompressed) disk space requirement is about the same,
since the emacs binary is a lot smaller.
I think the next steps are to look at actual live memory usage (which
will increase due to the non-duplication of objects, but not by an
entire megabyte because some of that data is relocations), and GC
performance (no prediction here, it could improve or deteriorate).
[0001-Remove-pure-space.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sun, 21 Jul 2019 13:46:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 36649 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Sun, 21 Jul 2019 12:53:21 +0000, Pip Cet <pipcet <at> gmail.com> said:
Pip> I think we should do (1) for now, since it simplifies the code enough
Pip> to introduce immutable objects "soon"; but until that time, we waste
Pip> more space on duplicate objects that we no longer know to be
Pip> immutable, so cannot merge.
Pip> I'm attaching a first patch that removes pure space, pinned symbols,
Pip> pinned objects, but keeps Fpurecopy (for hash consing), and doesn't
Pip> touch the Lisp codebase.
This doesnʼt build for me on macOS. After adjusting the parameters to
the call to make_hash_table in image.c, it crashes when dumping:
make[1]: Nothing to be done for `charscript.el'.
rm -f bootstrap-emacs.pdmp
./temacs --batch -l loadup --temacs=pbootstrap
make: *** [bootstrap-emacs.pdmp] Segmentation fault: 11
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
frame #0: 0x000000010016dc70 temacs`mark_object [inlined] symbol_marked_p(s=0x00080401003fdde0) at alloc.c:3741:14 [opt]
3738 {
3739 return pdumper_object_p (s)
3740 ? pdumper_marked_p (s)
-> 3741 : s->u.s.gcmarkbit;
3742 }
3743
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
* frame #0: 0x000000010016dc70 temacs`mark_object [inlined] symbol_marked_p(s=0x00080401003fdde0) at alloc.c:3741:14 [opt]
frame #1: 0x000000010016dc4c temacs`mark_object(arg=<unavailable>) at alloc.c:6082 [opt]
frame #2: 0x000000010016f30a temacs`mark_vectorlike(header=0x0000000101804000) at alloc.c:5666:5 [opt]
frame #3: 0x000000010016d6e0 temacs`mark_object(arg=<unavailable>) at alloc.c:5607:1 [opt] [artificial]
frame #4: 0x000000010016c4cc temacs`garbage_collect_1 [inlined] mark_object_root_visitor(root_ptr=<unavailable>, type=GC_ROOT_STATICPRO) at alloc.c:5303:3 [opt]
frame #5: 0x000000010016c4c4 temacs`garbage_collect_1 at alloc.c:5295 [opt]
frame #6: 0x000000010016c34f temacs`garbage_collect_1(gcst=0x00007ffeefbff248) at alloc.c:5427 [opt]
frame #7: 0x000000010016c114 temacs`garbage_collect at alloc.c:5551:3 [opt]
frame #8: 0x000000010019b836 temacs`eval_sub [inlined] maybe_gc at lisp.h:4974:5 [opt]
frame #9: 0x000000010019b824 temacs`eval_sub(form=0x000000010302e843) at eval.c:2166 [opt]
frame #10: 0x00000001001a023a temacs`Feval(form=0x000000010302e843, lexical=<unavailable>) at eval.c:2089:28 [opt]
frame #11: 0x000000010019f082 temacs`internal_condition_case(bfun=(temacs`top_level_2 at keyboard.c:1099), handlers=0x0000000000000090, hfun=(temacs`cmd_error at keyboard.c:919)) at eval.c:1347:25 [opt]
frame #12: 0x00000001001107ed temacs`top_level_1(ignore=<unavailable>) at keyboard.c:1108:5 [opt]
frame #13: 0x000000010019e617 temacs`internal_catch(tag=0x000000000000c420, func=(temacs`top_level_1 at keyboard.c:1105), arg=0x0000000000000000) at eval.c:1108:25 [opt]
frame #14: 0x00000001000fc16f temacs`command_loop at keyboard.c:1069:2 [opt]
frame #15: 0x00000001000fc093 temacs`recursive_edit_1 at keyboard.c:714:9 [opt]
frame #16: 0x00000001000fc3ac temacs`Frecursive_edit at keyboard.c:786:3 [opt]
frame #17: 0x00000001000fa9b1 temacs`main(argc=<unavailable>, argv=0x00007ffeefbff6b8) at emacs.c:2085:3 [opt]
frame #18: 0x00007fff7f9da3d5 libdyld.dylib`start + 1
frame #19: 0x00007fff7f9da3d5 libdyld.dylib`start + 1
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sun, 21 Jul 2019 14:38:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 36649 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Jul 21, 2019 at 1:44 PM Robert Pluim <rpluim <at> gmail.com> wrote:
> >>>>> On Sun, 21 Jul 2019 12:53:21 +0000, Pip Cet <pipcet <at> gmail.com> said:
> Pip> I think we should do (1) for now, since it simplifies the code enough
> Pip> to introduce immutable objects "soon"; but until that time, we waste
> Pip> more space on duplicate objects that we no longer know to be
> Pip> immutable, so cannot merge.
>
> Pip> I'm attaching a first patch that removes pure space, pinned symbols,
> Pip> pinned objects, but keeps Fpurecopy (for hash consing), and doesn't
> Pip> touch the Lisp codebase.
>
> This doesnʼt build for me on macOS. After adjusting the parameters to
> the call to make_hash_table in image.c, it crashes when dumping:
Thanks for testing! Indeed, I'd only verified it builds here.
My first guess is there's a symbol in the obarray which used to be
pinned, but is now collected before it is interned.
Can you try with the attached patch relative to the one I'd sent
before, and see what the output is?
[0001-debugging-changes.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sun, 21 Jul 2019 15:07:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 36649 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Sun, 21 Jul 2019 14:36:41 +0000, Pip Cet <pipcet <at> gmail.com> said:
Pip> On Sun, Jul 21, 2019 at 1:44 PM Robert Pluim <rpluim <at> gmail.com> wrote:
>> >>>>> On Sun, 21 Jul 2019 12:53:21 +0000, Pip Cet <pipcet <at> gmail.com> said:
Pip> I think we should do (1) for now, since it simplifies the code enough
Pip> to introduce immutable objects "soon"; but until that time, we waste
Pip> more space on duplicate objects that we no longer know to be
Pip> immutable, so cannot merge.
>>
Pip> I'm attaching a first patch that removes pure space, pinned symbols,
Pip> pinned objects, but keeps Fpurecopy (for hash consing), and doesn't
Pip> touch the Lisp codebase.
>>
>> This doesnʼt build for me on macOS. After adjusting the parameters to
>> the call to make_hash_table in image.c, it crashes when dumping:
Pip> Thanks for testing! Indeed, I'd only verified it builds here.
Pip> My first guess is there's a symbol in the obarray which used to be
Pip> pinned, but is now collected before it is interned.
Pip> Can you try with the attached patch relative to the one I'd sent
Pip> before, and see what the output is?
Hmm, it crashed the first time I ran make, then I got distracted, so I
ran make again later, and this time it built:
make[2]: Nothing to be done for `all'.
ELC char-fold.elc
freeing symbol def-tmp-var
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sun, 21 Jul 2019 17:44:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 36649 <at> debbugs.gnu.org (full text, mbox):
On Sun, Jul 21, 2019 at 3:06 PM Robert Pluim <rpluim <at> gmail.com> wrote:
> Hmm, it crashed the first time I ran make, then I got distracted, so I
> ran make again later, and this time it built:
>
> make[2]: Nothing to be done for `all'.
> ELC char-fold.elc
> freeing symbol def-tmp-var
Hmm. So it worked with the second patch, but only when you reran make?
That's strange. Looking at the crash backtrace again, it seems that
this is the initial garbage collection, when everything should be
pristine. I still think it dies while marking the obarray, upon
encountering a symbol which has somehow become corrupted...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sun, 21 Jul 2019 17:57:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 36649 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Sun, 21 Jul 2019 17:43:05 +0000, Pip Cet <pipcet <at> gmail.com> said:
Pip> On Sun, Jul 21, 2019 at 3:06 PM Robert Pluim <rpluim <at> gmail.com> wrote:
>> Hmm, it crashed the first time I ran make, then I got distracted, so I
>> ran make again later, and this time it built:
>>
>> make[2]: Nothing to be done for `all'.
>> ELC char-fold.elc
>> freeing symbol def-tmp-var
Pip> Hmm. So it worked with the second patch, but only when you reran make?
Pip> That's strange. Looking at the crash backtrace again, it seems that
Pip> this is the initial garbage collection, when everything should be
Pip> pristine. I still think it dies while marking the obarray, upon
Pip> encountering a symbol which has somehow become corrupted...
OK. How do we go about detecting which symbol that is?
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sun, 21 Jul 2019 18:09:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 36649 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Jul 21, 2019 at 5:56 PM Robert Pluim <rpluim <at> gmail.com> wrote:
> >>>>> On Sun, 21 Jul 2019 17:43:05 +0000, Pip Cet <pipcet <at> gmail.com> said:
>
> Pip> On Sun, Jul 21, 2019 at 3:06 PM Robert Pluim <rpluim <at> gmail.com> wrote:
> >> Hmm, it crashed the first time I ran make, then I got distracted, so I
> >> ran make again later, and this time it built:
> >>
> >> make[2]: Nothing to be done for `all'.
> >> ELC char-fold.elc
> >> freeing symbol def-tmp-var
>
> Pip> Hmm. So it worked with the second patch, but only when you reran make?
> Pip> That's strange. Looking at the crash backtrace again, it seems that
> Pip> this is the initial garbage collection, when everything should be
> Pip> pristine. I still think it dies while marking the obarray, upon
> Pip> encountering a symbol which has somehow become corrupted...
>
> OK. How do we go about detecting which symbol that is?
I'm not sure about debugging on macOS, but can you get a full
backtrace, or a core dump, or both? We're particularly interested in
what "i" is in mark_vectorlike.
Otherwise, the attached patch should produce (probably a lot of)
information, the last lines of which would be interesting...
[0001-Other-debugging-changes.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sun, 21 Jul 2019 18:16:03 GMT)
Full text and
rfc822 format available.
Message #32 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Date: Sun, 21 Jul 2019 19:56:42 +0200
> Cc: 36649 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
>
> Pip> That's strange. Looking at the crash backtrace again, it seems that
> Pip> this is the initial garbage collection, when everything should be
> Pip> pristine. I still think it dies while marking the obarray, upon
> Pip> encountering a symbol which has somehow become corrupted...
>
> OK. How do we go about detecting which symbol that is?
etc/DEBUG has some advice for debugging crashes inside GC.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sun, 21 Jul 2019 19:13:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 36649 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Sun, 21 Jul 2019 18:07:43 +0000, Pip Cet <pipcet <at> gmail.com> said:
Pip> I'm not sure about debugging on macOS, but can you get a full
Pip> backtrace, or a core dump, or both? We're particularly interested in
Pip> what "i" is in mark_vectorlike.
You want a lisp backtrace? I can always run under gdb if needed. As to
'i':
(lldb) up
frame #1: 0x000000010016dbec temacs`mark_object(arg=<unavailable>) at alloc.c:6082 [opt]
6079 {
6080 struct Lisp_Symbol *ptr = XSYMBOL (obj);
6081 nextsym:
-> 6082 if (symbol_marked_p (ptr))
6083 break;
6084 CHECK_ALLOCATED_AND_LIVE_SYMBOL ();
6085 set_symbol_marked(ptr);
(lldb)
frame #2: 0x000000010016f2aa temacs`mark_vectorlike(header=0x0000000101803200) at alloc.c:5666:5 [opt]
5663 The distinction is used e.g. by Lisp_Process which places extra
5664 non-Lisp_Object fields at the end of the structure... */
5665 for (i = 0; i < size; i++) /* ...and then mark its elements. */
-> 5666 mark_object (ptr->contents[i]);
5667 }
5668
5669 /* Like mark_vectorlike but optimized for char-tables (and
(lldb) p i
(ptrdiff_t) $0 = 0
(lldb) p ptr->contents
error: incomplete type 'Lisp_Object []' where a complete type is required
(lldb) p ptr->contents[0]
(Lisp_Object) $1 = 0x0008040000080400
Pip> Otherwise, the attached patch should produce (probably a lot of)
Pip> information, the last lines of which would be interesting...
Since you broke Robert's Second Rule of printf debugging, I stuck an
extra 'mark ' on the front of the fprintf in 'mark_vectorlike' :-)
0x10320c9e0 nil
0x10320c9e0 nil
0x10320c9e0 nil
0x10321ab70 z-group
0x10320c9e0 nil
0x10321a6f0 x-frame-parameter
0x10320ca40 unbound
0x10321aba0 zero-width
0x10320c9e0 nil
0x10320c9e0 nil
0x10320ca40 unbound
mark 0
make[1]: *** [bootstrap-emacs.pdmp] Segmentation fault: 11
make: *** [src] Error 2
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sun, 21 Jul 2019 19:36:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 36649 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Jul 21, 2019 at 7:12 PM Robert Pluim <rpluim <at> gmail.com> wrote:
> >>>>> On Sun, 21 Jul 2019 18:07:43 +0000, Pip Cet <pipcet <at> gmail.com> said:
> Pip> I'm not sure about debugging on macOS, but can you get a full
> Pip> backtrace, or a core dump, or both? We're particularly interested in
> Pip> what "i" is in mark_vectorlike.
>
> You want a lisp backtrace? I can always run under gdb if needed. As to
> 'i':
>
> (lldb) up
> frame #1: 0x000000010016dbec temacs`mark_object(arg=<unavailable>) at alloc.c:6082 [opt]
> 6079 {
> 6080 struct Lisp_Symbol *ptr = XSYMBOL (obj);
> 6081 nextsym:
> -> 6082 if (symbol_marked_p (ptr))
> 6083 break;
> 6084 CHECK_ALLOCATED_AND_LIVE_SYMBOL ();
> 6085 set_symbol_marked(ptr);
> (lldb)
> frame #2: 0x000000010016f2aa temacs`mark_vectorlike(header=0x0000000101803200) at alloc.c:5666:5 [opt]
> 5663 The distinction is used e.g. by Lisp_Process which places extra
> 5664 non-Lisp_Object fields at the end of the structure... */
> 5665 for (i = 0; i < size; i++) /* ...and then mark its elements. */
> -> 5666 mark_object (ptr->contents[i]);
> 5667 }
> 5668
> 5669 /* Like mark_vectorlike but optimized for char-tables (and
> (lldb) p i
> (ptrdiff_t) $0 = 0
> (lldb) p ptr->contents
> error: incomplete type 'Lisp_Object []' where a complete type is required
> (lldb) p ptr->contents[0]
> (Lisp_Object) $1 = 0x0008040000080400
Thanks! I messed up quite badly initializing the zero vector, it turns
out, so it was trying to initialize the first entry in the zero
vector, which, er, obviously wasn't a good idea :-)
Can you try again with this incremental patch?
[0001-Initialize-the-zero-vector-properly.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sun, 21 Jul 2019 20:21:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 36649 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Sun, 21 Jul 2019 19:35:01 +0000, Pip Cet <pipcet <at> gmail.com> said:
Pip> Thanks! I messed up quite badly initializing the zero vector, it turns
Pip> out, so it was trying to initialize the first entry in the zero
Pip> vector, which, er, obviously wasn't a good idea :-)
Pip> Can you try again with this incremental patch?
I offer two alternatives, both of which build and run:
diff --git i/src/alloc.c w/src/alloc.c
index 1b55ad8cab..206f0ce8d7 100644
--- i/src/alloc.c
+++ w/src/alloc.c
@@ -3091,7 +3091,7 @@ #define VECTOR_ELTS_MAX \
static struct Lisp_Vector *
allocate_vectorlike (ptrdiff_t len)
{
- eassert (0 < len && len <= VECTOR_ELTS_MAX);
+ eassert (0 <= len && len <= VECTOR_ELTS_MAX);
ptrdiff_t nbytes = header_size + len * word_size;
struct Lisp_Vector *p;
@@ -3151,8 +3151,8 @@ allocate_vector (ptrdiff_t len)
init_vectors (void)
{
zero_vector =
- make_lisp_ptr (allocate_vectorlike (sizeof (struct Lisp_Vector)),
- Lisp_Vectorlike);
+ make_lisp_ptr (allocate_vectorlike (0), Lisp_Vectorlike);
+ XVECTOR(zero_vector)->header.size = 0;
staticpro (&zero_vector);
}
diff --git i/src/alloc.c w/src/alloc.c
index 1b55ad8cab..294aa9a2aa 100644
--- i/src/alloc.c
+++ w/src/alloc.c
@@ -3151,8 +3151,8 @@ allocate_vector (ptrdiff_t len)
init_vectors (void)
{
zero_vector =
- make_lisp_ptr (allocate_vectorlike (sizeof (struct Lisp_Vector)),
- Lisp_Vectorlike);
+ make_lisp_ptr (allocate_vectorlike (1), Lisp_Vectorlike);
+ XVECTOR(zero_vector)->header.size = 0;
staticpro (&zero_vector);
}
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Mon, 22 Jul 2019 04:00:03 GMT)
Full text and
rfc822 format available.
Message #44 received at 36649 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Jul 21, 2019 at 8:20 PM Robert Pluim <rpluim <at> gmail.com> wrote:
> Pip> Can you try again with this incremental patch?
>
> I offer two alternatives, both of which build and run:
Oops, sorry. I think the second alternative might break
live_vector_holding, though?
Attaching an updated patch.
[0001-Remove-pure-space.patch.gz (application/gzip, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Mon, 22 Jul 2019 08:15:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 36649 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 22 Jul 2019 03:58:29 +0000, Pip Cet <pipcet <at> gmail.com> said:
Pip> On Sun, Jul 21, 2019 at 8:20 PM Robert Pluim <rpluim <at> gmail.com> wrote:
Pip> Can you try again with this incremental patch?
>>
>> I offer two alternatives, both of which build and run:
Pip> Oops, sorry. I think the second alternative might break
Pip> live_vector_holding, though?
OK. Hereʼs hoping no other code in emacs tries to create a 0-length
vector :-)
Pip> Attaching an updated patch.
I put this on top of it. The result builds, runs, and is sending this
email.
diff --git i/src/image.c w/src/image.c
index 355c849491..b21dff34d4 100644
--- i/src/image.c
+++ w/src/image.c
@@ -4596,7 +4596,7 @@ xpm_make_color_table_h (void (**put_func) (Lisp_Object, const char *, int,
*get_func = xpm_get_color_table_h;
return make_hash_table (hashtest_equal, DEFAULT_HASH_SIZE,
DEFAULT_REHASH_SIZE, DEFAULT_REHASH_THRESHOLD,
- Qnil, false);
+ Qnil);
}
static void
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Mon, 22 Jul 2019 14:31:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Date: Mon, 22 Jul 2019 10:14:47 +0200
> Cc: 36649 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
>
> >>>>> On Mon, 22 Jul 2019 03:58:29 +0000, Pip Cet <pipcet <at> gmail.com> said:
>
> Pip> On Sun, Jul 21, 2019 at 8:20 PM Robert Pluim <rpluim <at> gmail.com> wrote:
> Pip> Can you try again with this incremental patch?
> >>
> >> I offer two alternatives, both of which build and run:
>
> Pip> Oops, sorry. I think the second alternative might break
> Pip> live_vector_holding, though?
>
> OK. Hereʼs hoping no other code in emacs tries to create a 0-length
> vector :-)
I think font.c (or fontset.c?) does.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Mon, 22 Jul 2019 15:05:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 36649 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Jul 22, 2019 at 8:14 AM Robert Pluim <rpluim <at> gmail.com> wrote:
> >>>>> On Mon, 22 Jul 2019 03:58:29 +0000, Pip Cet <pipcet <at> gmail.com> said:
>
> Pip> On Sun, Jul 21, 2019 at 8:20 PM Robert Pluim <rpluim <at> gmail.com> wrote:
> Pip> Can you try again with this incremental patch?
> >>
> >> I offer two alternatives, both of which build and run:
>
> Pip> Oops, sorry. I think the second alternative might break
> Pip> live_vector_holding, though?
>
> OK. Hereʼs hoping no other code in emacs tries to create a 0-length
> vector :-)
By modifying header.size? That would be a problem. (I'd say no one
should ever do it, but I'd actually like to suggest it for hash
tables...)
> Pip> Attaching an updated patch.
>
> I put this on top of it. The result builds, runs, and is sending this
> email.
Hmm. Apparently I'm building without XPM? I should investigate that.
Anyway, there's another make_hash_table in emacs-module.c, but I think
that's it.
[0001-Remove-pure-space.patch.gz (application/gzip, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Mon, 22 Jul 2019 15:47:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 36649 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 22 Jul 2019 17:30:35 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Date: Mon, 22 Jul 2019 10:14:47 +0200
>> Cc: 36649 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
>>
>> >>>>> On Mon, 22 Jul 2019 03:58:29 +0000, Pip Cet <pipcet <at> gmail.com> said:
>>
Pip> On Sun, Jul 21, 2019 at 8:20 PM Robert Pluim <rpluim <at> gmail.com> wrote:
Pip> Can you try again with this incremental patch?
>> >>
>> >> I offer two alternatives, both of which build and run:
>>
Pip> Oops, sorry. I think the second alternative might break
Pip> live_vector_holding, though?
>>
>> OK. Hereʼs hoping no other code in emacs tries to create a 0-length
>> vector :-)
Eli> I think font.c (or fontset.c?) does.
If it does, that will be caught by allocate_vector, and this changes
allocate_vectorlike. Having said that, there are other callers of
allocate_vectorlike in alloc.c which donʼt check for a
zero-length. Maybe Iʼm over-worrying here.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Mon, 22 Jul 2019 18:47:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 36649 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 22 Jul 2019 15:03:55 +0000, Pip Cet <pipcet <at> gmail.com> said:
Pip> On Mon, Jul 22, 2019 at 8:14 AM Robert Pluim <rpluim <at> gmail.com> wrote:
>> >>>>> On Mon, 22 Jul 2019 03:58:29 +0000, Pip Cet <pipcet <at> gmail.com> said:
>>
Pip> On Sun, Jul 21, 2019 at 8:20 PM Robert Pluim <rpluim <at> gmail.com> wrote:
Pip> Can you try again with this incremental patch?
>> >>
>> >> I offer two alternatives, both of which build and run:
>>
Pip> Oops, sorry. I think the second alternative might break
Pip> live_vector_holding, though?
>>
>> OK. Hereʼs hoping no other code in emacs tries to create a 0-length
>> vector :-)
Pip> By modifying header.size? That would be a problem. (I'd say no one
Pip> should ever do it, but I'd actually like to suggest it for hash
Pip> tables...)
Pip> Attaching an updated patch.
It works for me. I think Iʼm with Eli on the prospect of putting this
in emacs-27, there are other things Iʼd like to see fixed first
(thereʼs still a potential TLS 1.3 issue that Iʼve not had time to
look at).
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Fri, 21 Aug 2020 12:53:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> gmail.com> writes:
> Pip> Attaching an updated patch.
>
> It works for me. I think Iʼm with Eli on the prospect of putting this
> in emacs-27, there are other things Iʼd like to see fixed first
> (thereʼs still a potential TLS 1.3 issue that Iʼve not had time to
> look at).
I didn't read this thread closely, but it seems like the conclusion that
this patch should have been applied. (It removes pure space,
apparently?)
The patch never was applied, though -- should it be applied now?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Fri, 21 Aug 2020 13:06:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 36649 <at> debbugs.gnu.org (full text, mbox):
On Fri, Aug 21, 2020 at 12:52 PM Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> I didn't read this thread closely, but it seems like the conclusion that
> this patch should have been applied. (It removes pure space,
> apparently?)
>
> The patch never was applied, though -- should it be applied now?
I believe it's best to be careful with this one. Pure space affects GC
in subtle ways, and it also affects performance.
See this thread:
https://lists.gnu.org/archive/html/emacs-devel/2019-07/msg00588.html
I'd be happy to set up a separate branch for removing pure space if
that's preferred.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Fri, 21 Aug 2020 13:48:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Pip Cet <pipcet <at> gmail.com>
> Date: Fri, 21 Aug 2020 13:04:47 +0000
> Cc: 36649 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
>
> On Fri, Aug 21, 2020 at 12:52 PM Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> > I didn't read this thread closely, but it seems like the conclusion that
> > this patch should have been applied. (It removes pure space,
> > apparently?)
> >
> > The patch never was applied, though -- should it be applied now?
>
> I believe it's best to be careful with this one. Pure space affects GC
> in subtle ways, and it also affects performance.
>
> See this thread:
> https://lists.gnu.org/archive/html/emacs-devel/2019-07/msg00588.html
>
> I'd be happy to set up a separate branch for removing pure space if
> that's preferred.
What do we do with unexec builds, which are still supported? Remove
that support? or ignore the possibility of an unexec build?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Fri, 21 Aug 2020 15:27:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 36649 <at> debbugs.gnu.org (full text, mbox):
On Aug 21 2020, Eli Zaretskii wrote:
> What do we do with unexec builds, which are still supported? Remove
> that support? or ignore the possibility of an unexec build?
What do we gain by keeping unexec alive?
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Fri, 21 Aug 2020 21:42:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 36649 <at> debbugs.gnu.org (full text, mbox):
On 8/21/20 6:47 AM, Eli Zaretskii wrote:
> What do we do with unexec builds, which are still supported? Remove
> that support? or ignore the possibility of an unexec build?
It's a good time to remove unexec support. Nobody is using it, there's a good
chance that it doesn't work nowadays on many platforms, and its continued
presence in the source code is costing us all more than it's benefiting.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sat, 22 Aug 2020 03:52:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 36649 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
I don't think we should desupport unexec while the pdumper is so new.
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sat, 22 Aug 2020 08:57:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 36649 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Aug 21, 2020 at 1:47 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Pip Cet <pipcet <at> gmail.com>
> > Date: Fri, 21 Aug 2020 13:04:47 +0000
> > Cc: 36649 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
> >
> > On Fri, Aug 21, 2020 at 12:52 PM Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> > > I didn't read this thread closely, but it seems like the conclusion that
> > > this patch should have been applied. (It removes pure space,
> > > apparently?)
> > >
> > > The patch never was applied, though -- should it be applied now?
> >
> > I believe it's best to be careful with this one. Pure space affects GC
> > in subtle ways, and it also affects performance.
> >
> > See this thread:
> > https://lists.gnu.org/archive/html/emacs-devel/2019-07/msg00588.html
> >
> > I'd be happy to set up a separate branch for removing pure space if
> > that's preferred.
>
> What do we do with unexec builds, which are still supported?
I think that's an important question, but I don't think it's strongly
connected to pure space.
In fact, it appears like unexec builds are currently broken on master,
and on this GNU/Linux machine, I've got to force use of HYBRID_MALLOC
to get an unexec build starting at all. But, having done that, it
works with and without the patch, at first glance.
Rebased patch attached (but I just noticed the commit message is no
longer complete).
[0001-Remove-pure-space.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sat, 22 Aug 2020 10:00:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 36649 <at> debbugs.gnu.org (full text, mbox):
On Aug 22 2020, Pip Cet wrote:
> +purecopy (Lisp_Object obj);
>
> DEFUN ("purecopy", Fpurecopy, Spurecopy, 1, 1, 0,
> doc: /* Make a copy of object OBJ in pure storage.
Perhaps purecopy should be dropped or made a no-op?
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sat, 22 Aug 2020 17:38:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 36649 <at> debbugs.gnu.org (full text, mbox):
On 8/22/20 1:55 AM, Pip Cet wrote:
> it appears like unexec builds are currently broken on master
At this point any effort to keep unexec builds working is wasted effort, except
perhaps as an exercise in nostalgia.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Fri, 28 Aug 2020 12:33:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 36649 <at> debbugs.gnu.org (full text, mbox):
On Sat, Aug 22, 2020 at 9:59 AM Andreas Schwab <schwab <at> linux-m68k.org> wrote:
> On Aug 22 2020, Pip Cet wrote:
> > +purecopy (Lisp_Object obj);
> >
> > DEFUN ("purecopy", Fpurecopy, Spurecopy, 1, 1, 0,
> > doc: /* Make a copy of object OBJ in pure storage.
>
> Perhaps purecopy should be dropped or made a no-op?
I believe that would be a logical next step, yes. The comment in
loadup.el says hash-consing saves "around 11% of pure space", which
sounds like it isn't worth the hassle to me.
So my suggestion would be to apply this patch first (removing the C
parts of pure space), then remove unexec, then turn purecopy into an
alias for identity and remove as many instances of it as possible.
Just as a reminder, we're still putting a 3 MB block of zero bytes
into every emacs binary...
Should this be discussed on emacs-devel? I've CC'd Andrea since I
believe the native-comp branch interacts with pure space in
complicated ways.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Fri, 28 Aug 2020 14:25:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Pip Cet <pipcet <at> gmail.com> writes:
> Should this be discussed on emacs-devel? I've CC'd Andrea since I
> believe the native-comp branch interacts with pure space in
> complicated ways.
Hi Pip,
thanks, as this gets into master I'll do the required modifications into
native-comp. It should bring some simplification in.
Ciao
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sun, 15 Nov 2020 15:21:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Pip Cet <pipcet <at> gmail.com> writes:
> On Sat, Aug 22, 2020 at 9:59 AM Andreas Schwab <schwab <at> linux-m68k.org> wrote:
>> On Aug 22 2020, Pip Cet wrote:
>> > +purecopy (Lisp_Object obj);
>> >
>> > DEFUN ("purecopy", Fpurecopy, Spurecopy, 1, 1, 0,
>> > doc: /* Make a copy of object OBJ in pure storage.
>>
>> Perhaps purecopy should be dropped or made a no-op?
>
> I believe that would be a logical next step, yes. The comment in
> loadup.el says hash-consing saves "around 11% of pure space", which
> sounds like it isn't worth the hassle to me.
>
> So my suggestion would be to apply this patch first (removing the C
> parts of pure space), then remove unexec, then turn purecopy into an
> alias for identity and remove as many instances of it as possible.
>
> Just as a reminder, we're still putting a 3 MB block of zero bytes
> into every emacs binary...
To me, the above sounds like a reasonable plan, given the discussion in
this thread and lack of any objections.
> Should this be discussed on emacs-devel?
Bringing this up on emacs-devel could perhaps get a few more eyes on
this before it lands on master. At the very least, it would inform
everyone about the planned change. So why not proceed to do that?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 03 Mar 2021 15:36:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 36649 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Nov 15, 2020 at 3:19 PM Stefan Kangas <stefankangas <at> gmail.com> wrote:
> Pip Cet <pipcet <at> gmail.com> writes:
> > On Sat, Aug 22, 2020 at 9:59 AM Andreas Schwab <schwab <at> linux-m68k.org> wrote:
> >> On Aug 22 2020, Pip Cet wrote:
> >
> > So my suggestion would be to apply this patch first (removing the C
> > parts of pure space), then remove unexec, then turn purecopy into an
> > alias for identity and remove as many instances of it as possible.
> >
> > Just as a reminder, we're still putting a 3 MB block of zero bytes
> > into every emacs binary...
>
> To me, the above sounds like a reasonable plan, given the discussion in
> this thread and lack of any objections.
Thanks.
> > Should this be discussed on emacs-devel?
>
> Bringing this up on emacs-devel could perhaps get a few more eyes on
> this before it lands on master. At the very least, it would inform
> everyone about the planned change. So why not proceed to do that?
I have time for that now, so here's a revised patch as a first step.
[0001-Remove-pure-space-Bug-36649.patch (text/x-patch, attachment)]
Added tag(s) patch.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Thu, 04 Mar 2021 11:36:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Thu, 04 Mar 2021 12:57:01 GMT)
Full text and
rfc822 format available.
Message #103 received at 36649 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Mar 3, 2021 at 3:34 PM Pip Cet <pipcet <at> gmail.com> wrote:
> I have time for that now, so here's a revised patch as a first step.
This patch removes pure space from Emacs 28.
Changes:
- now builds with --enable-checking=all
Todo:
- commit message not yet final.
- zero vector handling depends on Qnil being all zero in memory
[0001-Remove-pure-space-Bug-36649.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Thu, 04 Mar 2021 14:57:02 GMT)
Full text and
rfc822 format available.
Message #106 received at 36649 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 4 Mar 2021 12:55:34 +0000, Pip Cet <pipcet <at> gmail.com> said:
Pip> On Wed, Mar 3, 2021 at 3:34 PM Pip Cet <pipcet <at> gmail.com> wrote:
>> I have time for that now, so here's a revised patch as a first step.
Pip> This patch removes pure space from Emacs 28.
Cool! Finally! Commit && push, damn the torpedoes.
Pip> Changes:
Pip> - now builds with --enable-checking=all
Pip> Todo:
Pip> - commit message not yet final.
Pip> - zero vector handling depends on Qnil being all zero in memory
I think Emacs already assumes Qnil == 0, since there are places that
use ! to check for Qnil rather than using NILP.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Thu, 04 Mar 2021 15:50:02 GMT)
Full text and
rfc822 format available.
Message #109 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Date: Thu, 04 Mar 2021 15:56:10 +0100
> Cc: eggert <at> cs.ucla.edu, Andreas Schwab <schwab <at> linux-m68k.org>,
> Stefan Kangas <stefankangas <at> gmail.com>, 36649 <at> debbugs.gnu.org, larsi <at> gnus.org,
> Andrea Corallo <akrl <at> sdf.org>
>
> I think Emacs already assumes Qnil == 0, since there are places that
> use ! to check for Qnil rather than using NILP.
Those are bugs that need to be fixed. Fast.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Thu, 04 Mar 2021 16:44:02 GMT)
Full text and
rfc822 format available.
Message #112 received at 36649 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 04 Mar 2021 17:49:21 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Date: Thu, 04 Mar 2021 15:56:10 +0100
>> Cc: eggert <at> cs.ucla.edu, Andreas Schwab <schwab <at> linux-m68k.org>,
>> Stefan Kangas <stefankangas <at> gmail.com>, 36649 <at> debbugs.gnu.org, larsi <at> gnus.org,
>> Andrea Corallo <akrl <at> sdf.org>
>>
>> I think Emacs already assumes Qnil == 0, since there are places that
>> use ! to check for Qnil rather than using NILP.
Eli> Those are bugs that need to be fixed. Fast.
Hmm,
./configure --enable-check-lisp-object-type
for emacs-master and emacs-27 builds fine, so maybe Iʼm imagining things.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Thu, 04 Mar 2021 16:54:01 GMT)
Full text and
rfc822 format available.
Message #115 received at 36649 <at> debbugs.gnu.org (full text, mbox):
>> I think Emacs already assumes Qnil == 0, since there are places that
>> use ! to check for Qnil rather than using NILP.
>
> Those are bugs that need to be fixed. Fast.
Here this would get me
../../src/window.c: In function ‘select_window’:
../../src/window.c:535:7: error: wrong type argument to unary exclamation mark
if (!norecord || EQ (norecord, Qmark_for_redisplay))
^
or
CC window.o
../../src/window.c: In function ‘select_window’:
../../src/window.c:535:17: error: invalid operands to binary == (have ‘Lisp_Object’ {aka ‘struct Lisp_Object’} and ‘int’)
if ((norecord == false) || EQ (norecord, Qmark_for_redisplay))
^~
so I cannot imagine that we really had such bugs. Unless you mean Lisp
variables explicitly defined via DEFVAR_BOOL.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Thu, 04 Mar 2021 17:08:01 GMT)
Full text and
rfc822 format available.
Message #118 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: pipcet <at> gmail.com, eggert <at> cs.ucla.edu, schwab <at> linux-m68k.org,
> stefankangas <at> gmail.com, 36649 <at> debbugs.gnu.org, larsi <at> gnus.org,
> akrl <at> sdf.org
> Date: Thu, 04 Mar 2021 17:42:56 +0100
>
> >> I think Emacs already assumes Qnil == 0, since there are places that
> >> use ! to check for Qnil rather than using NILP.
>
> Eli> Those are bugs that need to be fixed. Fast.
>
> Hmm,
>
> ./configure --enable-check-lisp-object-type
>
> for emacs-master and emacs-27 builds fine, so maybe Iʼm imagining things.
"Imagination is more important than knowledge". Albert Einstein.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Thu, 04 Mar 2021 17:19:02 GMT)
Full text and
rfc822 format available.
Message #121 received at 36649 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 04 Mar 2021 19:07:01 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Cc: pipcet <at> gmail.com, eggert <at> cs.ucla.edu, schwab <at> linux-m68k.org,
>> stefankangas <at> gmail.com, 36649 <at> debbugs.gnu.org, larsi <at> gnus.org,
>> akrl <at> sdf.org
>> Date: Thu, 04 Mar 2021 17:42:56 +0100
>>
>> >> I think Emacs already assumes Qnil == 0, since there are places that
>> >> use ! to check for Qnil rather than using NILP.
>>
Eli> Those are bugs that need to be fixed. Fast.
>>
>> Hmm,
>>
>> ./configure --enable-check-lisp-object-type
>>
>> for emacs-master and emacs-27 builds fine, so maybe Iʼm imagining things.
Eli> "Imagination is more important than knowledge". Albert Einstein.
:-) Tell that to the compiler
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Thu, 04 Mar 2021 17:46:02 GMT)
Full text and
rfc822 format available.
Message #124 received at submit <at> debbugs.gnu.org (full text, mbox):
On Thu 04 Mar 2021, Eli Zaretskii wrote:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Date: Thu, 04 Mar 2021 15:56:10 +0100
>> Cc: eggert <at> cs.ucla.edu, Andreas Schwab <schwab <at> linux-m68k.org>,
>> Stefan Kangas <stefankangas <at> gmail.com>, 36649 <at> debbugs.gnu.org, larsi <at> gnus.org,
>> Andrea Corallo <akrl <at> sdf.org>
>>
>> I think Emacs already assumes Qnil == 0, since there are places that
>> use ! to check for Qnil rather than using NILP.
>
> Those are bugs that need to be fixed. Fast.
Agree that they are bugs, but also see NIL_IS_ZERO and memclear() in lisp.h.
AndyM
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Thu, 04 Mar 2021 21:53:02 GMT)
Full text and
rfc822 format available.
Message #127 received at 36649 <at> debbugs.gnu.org (full text, mbox):
On 3/4/21 6:56 AM, Robert Pluim wrote:
> Pip> - zero vector handling depends on Qnil being all zero in memory
>
> I think Emacs already assumes Qnil == 0, since there are places that
> use ! to check for Qnil rather than using NILP.
The convention is to put a "verify (NIL_IS_ZERO);" near the rare bits of
code that assume Qnil is all-bits-zero. This is to help out any
hypothetical future developer who wants to change Qnil to be some other
value. Currently there are only two such locations. (There is one other
location that uses NIL_IS_ZERO for an optimization.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Fri, 05 Mar 2021 03:01:02 GMT)
Full text and
rfc822 format available.
Message #130 received at 36649 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, Mar 4, 2021 at 9:52 PM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> On 3/4/21 6:56 AM, Robert Pluim wrote:
> > Pip> - zero vector handling depends on Qnil being all zero in memory
> >
> > I think Emacs already assumes Qnil == 0, since there are places that
> > use ! to check for Qnil rather than using NILP.
>
> The convention is to put a "verify (NIL_IS_ZERO);" near the rare bits of
> code that assume Qnil is all-bits-zero.
That would be nice, but I'm quite certain there are places in the code
that rely on this identity without doing that...
> This is to help out any
> hypothetical future developer who wants to change Qnil to be some other
> value. Currently there are only two such locations. (There is one other
> location that uses NIL_IS_ZERO for an optimization.)
When I did the NaN boxing thing, I remember seeing quite a few 0.0s
popping up where I was expecting nil :-)
Anyway, it's easy enough to remove the assumption. Here's the current patch.
Pip
[0001-Remove-pure-space-Bug-36649.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Fri, 05 Mar 2021 07:21:02 GMT)
Full text and
rfc822 format available.
Message #133 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Pip Cet <pipcet <at> gmail.com>
> Date: Fri, 5 Mar 2021 03:00:03 +0000
> Cc: Robert Pluim <rpluim <at> gmail.com>, Andreas Schwab <schwab <at> linux-m68k.org>,
> Stefan Kangas <stefankangas <at> gmail.com>, 36649 <at> debbugs.gnu.org, larsi <at> gnus.org,
> Andrea Corallo <akrl <at> sdf.org>
>
> > The convention is to put a "verify (NIL_IS_ZERO);" near the rare bits of
> > code that assume Qnil is all-bits-zero.
>
> That would be nice, but I'm quite certain there are places in the code
> that rely on this identity without doing that...
There shouldn't be. If you find them, please report them.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sun, 14 Mar 2021 22:20:01 GMT)
Full text and
rfc822 format available.
Message #136 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> Anyway, it's easy enough to remove the assumption. Here's the current patch.
Is anything still blocking this patch or can it go in?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 12 May 2021 14:52:02 GMT)
Full text and
rfc822 format available.
Message #139 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> Anyway, it's easy enough to remove the assumption. Here's the current patch.
>
> Is anything still blocking this patch or can it go in?
Skimming this thread, it seems like most people were very enthusiastic
about removing pure space, but this patch was never applied.
Eli, did you have any objections? If not, it sounds like a good idea to
me, too.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 12 May 2021 15:02:02 GMT)
Full text and
rfc822 format available.
Message #142 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Pip Cet <pipcet <at> gmail.com>, Paul Eggert <eggert <at> cs.ucla.edu>, Robert
> Pluim <rpluim <at> gmail.com>, Andreas Schwab <schwab <at> linux-m68k.org>, Stefan
> Kangas <stefankangas <at> gmail.com>, 36649 <at> debbugs.gnu.org, Andrea Corallo
> <akrl <at> sdf.org>, Eli Zaretskii <eliz <at> gnu.org>
> Date: Wed, 12 May 2021 16:50:46 +0200
>
> Eli, did you have any objections? If not, it sounds like a good idea to
> me, too.
I don't have any objections, but there was one issue on which we
didn't reach any agreed conclusions:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36649#68
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 12 May 2021 17:04:01 GMT)
Full text and
rfc822 format available.
Message #145 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> I don't have any objections, but there was one issue on which we
> didn't reach any agreed conclusions:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36649#68
Right -- what to do about unexec builds? Was the plan to stop
supporting that in this cycle or the next?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 12 May 2021 17:07:01 GMT)
Full text and
rfc822 format available.
Message #148 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen [2021-05-12 19:03:19] wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>> I don't have any objections, but there was one issue on which we
>> didn't reach any agreed conclusions:
>>
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36649#68
>
> Right -- what to do about unexec builds? Was the plan to stop
> supporting that in this cycle or the next?
I thought the question was not directly relevant because removal of the
pure space does not imply removing unexec.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 12 May 2021 17:12:01 GMT)
Full text and
rfc822 format available.
Message #151 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: monnier <at> iro.umontreal.ca, pipcet <at> gmail.com, eggert <at> cs.ucla.edu,
> rpluim <at> gmail.com, schwab <at> linux-m68k.org, stefankangas <at> gmail.com,
> 36649 <at> debbugs.gnu.org, akrl <at> sdf.org
> Date: Wed, 12 May 2021 19:03:19 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > I don't have any objections, but there was one issue on which we
> > didn't reach any agreed conclusions:
> >
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36649#68
>
> Right -- what to do about unexec builds? Was the plan to stop
> supporting that in this cycle or the next?
I think we should keep unexec in Emacs 28 and remove it in Emacs 29.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 12 May 2021 17:12:02 GMT)
Full text and
rfc822 format available.
Message #154 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> I thought the question was not directly relevant because removal of the
> pure space does not imply removing unexec.
It just makes unexec Emacs a little less efficient? In which case I say
we should just ignore the issue and apply the patch.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 12 May 2021 17:20:02 GMT)
Full text and
rfc822 format available.
Message #157 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, pipcet <at> gmail.com, eggert <at> cs.ucla.edu,
> rpluim <at> gmail.com, schwab <at> linux-m68k.org, stefan <at> marxist.se,
> 36649 <at> debbugs.gnu.org, akrl <at> sdf.org
> Date: Wed, 12 May 2021 13:06:24 -0400
>
> >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36649#68
> >
> > Right -- what to do about unexec builds? Was the plan to stop
> > supporting that in this cycle or the next?
>
> I thought the question was not directly relevant because removal of the
> pure space does not imply removing unexec.
The beginning of the bug discussion explains why they are related.
Specifically: (a) the motivation for removing purespace comes from the
pdumper build, and (b) we don't want to waste efforts on fixing
possible breakage of the unexec build as result of this change.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 12 May 2021 17:25:01 GMT)
Full text and
rfc822 format available.
Message #160 received at 36649 <at> debbugs.gnu.org (full text, mbox):
I had a look at the patch to see whether it had diverged from the
current code base a lot -- and it mostly applies. The major thing
that's changed, though, is that comp.c has a lot of code to handle
purespace, and those bits have to be removed, too.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 12 May 2021 17:30:01 GMT)
Full text and
rfc822 format available.
Message #163 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, pipcet <at> gmail.com, eggert <at> cs.ucla.edu,
> rpluim <at> gmail.com, schwab <at> linux-m68k.org, stefan <at> marxist.se,
> 36649 <at> debbugs.gnu.org, akrl <at> sdf.org
> Date: Wed, 12 May 2021 19:11:21 +0200
>
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
> > I thought the question was not directly relevant because removal of the
> > pure space does not imply removing unexec.
>
> It just makes unexec Emacs a little less efficient? In which case I say
> we should just ignore the issue and apply the patch.
Keeping unexec doesn't mean breaking it . If we believe someone might
need that configuration, then we should give them a full-fledged
Emacs, not a crippled one.
The patch can easily be tweaked to make the changes conditioned by
HAVE_PDUMPER, so I believe there's no need to argue about this nit:
let's simply remove purespace from the pdumper builds, and leave it
alone in the unexec builds.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 12 May 2021 17:33:01 GMT)
Full text and
rfc822 format available.
Message #166 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Keeping unexec doesn't mean breaking it . If we believe someone might
> need that configuration, then we should give them a full-fledged
> Emacs, not a crippled one.
How crippled are we talking?
> The patch can easily be tweaked to make the changes conditioned by
> HAVE_PDUMPER, so I believe there's no need to argue about this nit:
> let's simply remove purespace from the pdumper builds, and leave it
> alone in the unexec builds.
That would be a whole lot of #ifs in the code, and wouldn't make the
change worth it -- in that case, I'd rather wait until we get rid of
unexec before getting rid of pure space.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 12 May 2021 17:38:01 GMT)
Full text and
rfc822 format available.
Message #169 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> Keeping unexec doesn't mean breaking it. If we believe someone might
> need that configuration, then we should give them a full-fledged
> Emacs, not a crippled one.
Removing pure space from unexec builds doesn't make them
crippled, AFAIK.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 12 May 2021 17:43:05 GMT)
Full text and
rfc822 format available.
Message #172 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: monnier <at> iro.umontreal.ca, pipcet <at> gmail.com, eggert <at> cs.ucla.edu,
> rpluim <at> gmail.com, schwab <at> linux-m68k.org, stefan <at> marxist.se,
> 36649 <at> debbugs.gnu.org, akrl <at> sdf.org
> Date: Wed, 12 May 2021 19:32:13 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Keeping unexec doesn't mean breaking it . If we believe someone might
> > need that configuration, then we should give them a full-fledged
> > Emacs, not a crippled one.
>
> How crippled are we talking?
As in "less efficient".
> > The patch can easily be tweaked to make the changes conditioned by
> > HAVE_PDUMPER, so I believe there's no need to argue about this nit:
> > let's simply remove purespace from the pdumper builds, and leave it
> > alone in the unexec builds.
>
> That would be a whole lot of #ifs in the code, and wouldn't make the
> change worth it -- in that case, I'd rather wait until we get rid of
> unexec before getting rid of pure space.
I don't think it will be so ugly as being prohibitive: we already have
quite a few of "#if HAVE_PDUMPER" in the sources. But if you prefer
to wait with purespace removal until after unexec is removed, I don't
mind too much: Emacs 28 will have quite a lot of important changes
even without that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 12 May 2021 17:46:02 GMT)
Full text and
rfc822 format available.
Message #175 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, pipcet <at> gmail.com,
> eggert <at> cs.ucla.edu, rpluim <at> gmail.com, schwab <at> linux-m68k.org,
> stefan <at> marxist.se, 36649 <at> debbugs.gnu.org, akrl <at> sdf.org
> Date: Wed, 12 May 2021 13:37:43 -0400
>
> > Keeping unexec doesn't mean breaking it. If we believe someone might
> > need that configuration, then we should give them a full-fledged
> > Emacs, not a crippled one.
>
> Removing pure space from unexec builds doesn't make them
> crippled, AFAIK.
I just don't want to risk that, not at all. Because if we are missing
something, it will require efforts I'd rather put elsewhere.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 12 May 2021 18:00:02 GMT)
Full text and
rfc822 format available.
Message #178 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> How crippled are we talking?
>
> As in "less efficient".
As long as it doesn't render the unexec Emacs unusably slow, I think
that's OK for a thing that's on its way out.
Hm... I wonder whether it would be easy to get some numbers. I'll try
to get an unexec build (without purespace) running and see how bad it is.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 12 May 2021 18:03:01 GMT)
Full text and
rfc822 format available.
Message #181 received at 36649 <at> debbugs.gnu.org (full text, mbox):
On 5/12/21 10:32 AM, Lars Ingebrigtsen wrote:
> That would be a whole lot of #ifs in the code, and wouldn't make the
> change worth it -- in that case, I'd rather wait until we get rid of
> unexec before getting rid of pure space.
+1. It's not worth the hassle. Just wait. We've got time.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 12 May 2021 18:26:01 GMT)
Full text and
rfc822 format available.
Message #184 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Hm... I wonder whether it would be easy to get some numbers. I'll try
> to get an unexec build (without purespace) running and see how bad it is.
Easier said than done. Is this how it's supposed to be done?
./configure --with-unexec=yes --with-dumping=unexec
In that case, Emacs just segfaults:
make[2]: Entering directory '/home/larsi/src/emacs/pure/lisp'
ELC international/titdic-cnv.elc
Fatal error 11: Segmentation fault
Backtrace:
../src/bootstrap-emacs[0x525571]
../src/bootstrap-emacs[0x4203b6]
../src/bootstrap-emacs[0x420889]
../src/bootstrap-emacs[0x523b5d]
../src/bootstrap-emacs[0x523bd9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x14140)[0x7f3d1517c140]
So I'm not able to build an unexec build on GNU/Linux at all.
If this is the case in general, and not just here on this
Debian/bullseye system, then I think we should consider getting rid of
both unexec and pure space now, and not wait any longer.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 12 May 2021 18:39:01 GMT)
Full text and
rfc822 format available.
Message #187 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: eggert <at> cs.ucla.edu, rpluim <at> gmail.com, stefan <at> marxist.se,
> schwab <at> linux-m68k.org, monnier <at> iro.umontreal.ca, pipcet <at> gmail.com,
> 36649 <at> debbugs.gnu.org, akrl <at> sdf.org
> Date: Wed, 12 May 2021 20:25:21 +0200
>
> make[2]: Entering directory '/home/larsi/src/emacs/pure/lisp'
> ELC international/titdic-cnv.elc
> Fatal error 11: Segmentation fault
> Backtrace:
> ../src/bootstrap-emacs[0x525571]
> ../src/bootstrap-emacs[0x4203b6]
> ../src/bootstrap-emacs[0x420889]
> ../src/bootstrap-emacs[0x523b5d]
> ../src/bootstrap-emacs[0x523bd9]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x14140)[0x7f3d1517c140]
>
> So I'm not able to build an unexec build on GNU/Linux at all.
>
> If this is the case in general, and not just here on this
> Debian/bullseye system, then I think we should consider getting rid of
> both unexec and pure space now, and not wait any longer.
Someone built the master branch with unexec just a few days ago, see
https://lists.gnu.org/archive/html/emacs-devel/2021-05/msg00060.html
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 12 May 2021 18:49:01 GMT)
Full text and
rfc822 format available.
Message #190 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Someone built the master branch with unexec just a few days ago, see
>
> https://lists.gnu.org/archive/html/emacs-devel/2021-05/msg00060.html
That's on Windows, though, and I seem to recall you fixing unexec on
Windows a couple weeks ago?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 12 May 2021 18:53:02 GMT)
Full text and
rfc822 format available.
Message #193 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: eggert <at> cs.ucla.edu, rpluim <at> gmail.com, stefan <at> marxist.se,
> schwab <at> linux-m68k.org, monnier <at> iro.umontreal.ca, pipcet <at> gmail.com,
> 36649 <at> debbugs.gnu.org, akrl <at> sdf.org
> Date: Wed, 12 May 2021 20:48:28 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Someone built the master branch with unexec just a few days ago, see
> >
> > https://lists.gnu.org/archive/html/emacs-devel/2021-05/msg00060.html
>
> That's on Windows, though, and I seem to recall you fixing unexec on
> Windows a couple weeks ago?
I worked with him to fix it, yes. But the problem and the fix were
not Windows specific, AFAIR. I guess there's more, and perhaps it
happens only on systems which don't use mmap for buffer text. I will
try to take a look when I have time.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 12 May 2021 19:08:02 GMT)
Full text and
rfc822 format available.
Message #196 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Or... is this the way do get an unexec build these days?
./configure --with-unexec=yes --with-dumping=none
This does not segfault here. I'll try to get some timings done with the
pure space removal + unexec, then...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 12 May 2021 19:08:02 GMT)
Full text and
rfc822 format available.
Message #199 received at 36649 <at> debbugs.gnu.org (full text, mbox):
>> > Keeping unexec doesn't mean breaking it. If we believe someone might
>> > need that configuration, then we should give them a full-fledged
>> > Emacs, not a crippled one.
>>
>> Removing pure space from unexec builds doesn't make them
>> crippled, AFAIK.
>
> I just don't want to risk that, not at all. Because if we are missing
> something, it will require efforts I'd rather put elsewhere.
I can see a risk that removing purespace will break unexec because of
some oversight of some detail somewhere (simply because it's
a configuration that's basically never tested), but I can't imagine the
breakage to be hard to fix: running without purespace has been used
during the bootstrap for many many years, both with pdump and with
unexec, so it's really not "special".
The only real consequence will be a slightly worse performance, but no
worse than what we get with pdump anyway ;-)
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 12 May 2021 19:13:01 GMT)
Full text and
rfc822 format available.
Message #202 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: eggert <at> cs.ucla.edu, rpluim <at> gmail.com, stefan <at> marxist.se,
> schwab <at> linux-m68k.org, monnier <at> iro.umontreal.ca, pipcet <at> gmail.com,
> 36649 <at> debbugs.gnu.org, akrl <at> sdf.org
> Date: Wed, 12 May 2021 21:07:00 +0200
>
> Or... is this the way do get an unexec build these days?
>
> ./configure --with-unexec=yes --with-dumping=none
>
> This does not segfault here. I'll try to get some timings done with the
> pure space removal + unexec, then...
I don't know if this is an interesting configuration. AFAIU,
"--with-dumping=none" means you run the CANNOT_DUMP version, which
doesn't dump Emacs at all.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 12 May 2021 19:14:02 GMT)
Full text and
rfc822 format available.
Message #205 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen [2021-05-12 19:58:46] wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>>> How crippled are we talking?
>> As in "less efficient".
It will be less efficient, indeed, because the GC will take longer
because it will also traverse the part of the heap that used to live in
the purespace. This effect is more noticeable in sessions where the
heap is small (and hence what used to be purespace represents a more
significant fraction of the total) and becomes unmeasurable once the
heap becomes large enough to dwarf the purespace.
But please note that we have all been living with exactly this
inefficiency ever since we started using pdump. So while it will be
slightly less efficient, it will still be as efficient as what we get
with pdump, which I believe we all consider as acceptable.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 12 May 2021 19:18:01 GMT)
Full text and
rfc822 format available.
Message #208 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: larsi <at> gnus.org, pipcet <at> gmail.com, eggert <at> cs.ucla.edu,
> rpluim <at> gmail.com, schwab <at> linux-m68k.org, stefan <at> marxist.se,
> 36649 <at> debbugs.gnu.org, akrl <at> sdf.org
> Date: Wed, 12 May 2021 15:07:42 -0400
>
> > I just don't want to risk that, not at all. Because if we are missing
> > something, it will require efforts I'd rather put elsewhere.
>
> I can see a risk that removing purespace will break unexec because of
> some oversight of some detail somewhere (simply because it's
> a configuration that's basically never tested), but I can't imagine the
> breakage to be hard to fix: running without purespace has been used
> during the bootstrap for many many years, both with pdump and with
> unexec, so it's really not "special".
Last time I needed to fix a breakage in the unexec build it took a
non-trivial effort, and would have probably taken even more, had I not
been fortunate to have a user who could investigate the problems on
his own and present clear and correct causes of the problems.
So my bitter experience doesn't confirm your optimism.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 12 May 2021 19:45:01 GMT)
Full text and
rfc822 format available.
Message #211 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> I don't know if this is an interesting configuration. AFAIU,
> "--with-dumping=none" means you run the CANNOT_DUMP version, which
> doesn't dump Emacs at all.
Ah, yes... and in that case I guess there is no pure space? Oh well, I
guess somebody has to look into getting unexec working on Linux if we're
to, er, see what the impact of pure space unexec would have been. If it
was working. :-)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Thu, 13 May 2021 14:09:02 GMT)
Full text and
rfc822 format available.
Message #214 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 12 May 2021 21:52:31 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: eggert <at> cs.ucla.edu, rpluim <at> gmail.com, stefan <at> marxist.se,
> schwab <at> linux-m68k.org, monnier <at> iro.umontreal.ca, pipcet <at> gmail.com,
> 36649 <at> debbugs.gnu.org, akrl <at> sdf.org
>
> I worked with him to fix it, yes. But the problem and the fix were
> not Windows specific, AFAIR. I guess there's more, and perhaps it
> happens only on systems which don't use mmap for buffer text. I will
> try to take a look when I have time.
Looks like some memory problem: xrealloc segfaults.
Don't we need to disable ASLR for unexec to work? And doesn't that
require setfattr or paxctl commands to be available? If not, how do
we disable ASLR in bootstrap-emacs and emacs binaries on GNU/Linux?
Here's the backtrace from the crash I see:
Thread 1 "bootstrap-emacs" received signal SIGSEGV, Segmentation fault.
0x00007ffff21f4917 in _int_realloc (av=av <at> entry=0x7ffff254ac40 <main_arena>,
oldp=oldp <at> entry=0x24a73b0, oldsize=oldsize <at> entry=32, nb=nb <at> entry=144)
at malloc.c:4589
4589 malloc.c: No such file or directory.
(gdb) bt
#0 0x00007ffff21f4917 in _int_realloc (av=av <at> entry=0x7ffff254ac40 <main_arena>, oldp=oldp <at> entry=0x24a73b0, oldsize=oldsize <at> entry=32, nb=nb <at> entry=144)
at malloc.c:4589
#1 0x00007ffff21f80db in __GI___libc_realloc (oldmem=0x24a73c0, bytes=128)
at malloc.c:3240
#2 0x0000000000664a28 in lrealloc (p=0x24a73c0, size=128) at alloc.c:1378
#3 0x0000000000663e46 in xrealloc (block=0x24a73c0, size=128) at alloc.c:804
#4 0x00000000006641f9 in xpalloc (pa=0x24a73c0, nitems=0xed8450 <searchbufs+1840>, nitems_incr_min=1, nitems_max=32768, item_size=1) at alloc.c:928
#5 0x0000000000658823 in regex_compile (pattern=0x8011b8 "^;;;.\\(in Emacs version\\|bytecomp version FSF\\)", size=47, posix_backtracking=false, whitespace_regexp=0x0, bufp=0xed8448 <searchbufs+1832>) at regex-emacs.c:2617
#6 0x0000000000660493 in rpl_re_compile_pattern (pattern=0x8011b8 "^;;;.\\(in Emacs version\\|bytecomp version FSF\\)", length=47, posix_backtracking=false, whitespace_regexp=0x0, bufp=0xed8448 <searchbufs+1832>) at regex-emacs.c:5116
#7 0x00000000006456eb in compile_pattern_1 (cp=0xed8428 <searchbufs+1800>, pattern=XIL(0xaa125c), translate=XIL(0x19b7125), posix=false) at search.c:123
#8 0x0000000000645b2f in compile_pattern (pattern=XIL(0xaa125c), regp=0x0, translate=XIL(0x19b7125), posix=false, multibyte=false) at search.c:237
#9 0x0000000000646707 in fast_c_string_match_ignore_case (regexp=XIL(0xaa125c), string=0x7fffffffd09d "\n;; certain of its subdirectories. Here we specify them.\n(normal-top-level-add-to-load-path '(\"vc\" \"url\" \"textmodes\" \"progmodes\" \"play\" \"org\" \"nxml\" \"net\" \"mh-e\" \"mail\" \"leim\" \"language\" \"internation"..., len=401) at search.c:497
#10 0x00000000006dc284 in safe_to_load_version (fd=5) at lread.c:1060
#11 0x00000000006dd06b in Fload (file=XIL(0x2556774), noerror=XIL(0x30), nomessage=XIL(0x30), nosuffix=XIL(0x30), must_suffix=XIL(0)) at lread.c:1398
#12 0x000000000069b971 in eval_sub (form=XIL(0x1e70b03)) at eval.c:2525
#13 0x0000000000695602 in Fprogn (body=XIL(0)) at eval.c:471
#14 0x0000000000697784 in Flet (args=XIL(0x1e70b13)) at eval.c:1057
#15 0x000000000069b451 in eval_sub (form=XIL(0x1e70b83)) at eval.c:2464
#16 0x0000000000695602 in Fprogn (body=XIL(0x1e70863)) at eval.c:471
#17 0x0000000000695636 in prog_ignore (body=XIL(0x1e70b93)) at eval.c:482
#18 0x000000000069785a in Fwhile (args=XIL(0x1e71553)) at eval.c:1078
#19 0x000000000069b451 in eval_sub (form=XIL(0x1e71563)) at eval.c:2464
#20 0x0000000000695602 in Fprogn (body=XIL(0)) at eval.c:471
#21 0x0000000000697784 in Flet (args=XIL(0x1e71573)) at eval.c:1057
---Type <return> to continue, or q <return> to quit---
#22 0x000000000069b451 in eval_sub (form=XIL(0x1e71653)) at eval.c:2464
#23 0x0000000000695602 in Fprogn (body=XIL(0x1d26063)) at eval.c:471
#24 0x00000000006953c9 in Fif (args=XIL(0x1e41753)) at eval.c:427
#25 0x000000000069b451 in eval_sub (form=XIL(0x1e41763)) at eval.c:2464
#26 0x0000000000695602 in Fprogn (body=XIL(0)) at eval.c:471
#27 0x000000000069e40b in funcall_lambda (fun=XIL(0x1d03ba3), nargs=0, arg_vector=0x7fffffffde00) at eval.c:3313
#28 0x000000000069dc30 in apply_lambda (fun=XIL(0x1d03b93), args=XIL(0), count=4) at eval.c:3185
#29 0x000000000069bcd4 in eval_sub (form=XIL(0x17d0813)) at eval.c:2588
#30 0x000000000069ad2b in Feval (form=XIL(0x17d0813), lexical=XIL(0))
at eval.c:2340
#31 0x00000000005c4a3e in top_level_2 () at keyboard.c:1103
#32 0x0000000000698abb in internal_condition_case (bfun=0x5c4a1b <top_level_2>, handlers=XIL(0x90), hfun=0x5c43dd <cmd_error>) at eval.c:1475
#33 0x00000000005c4a86 in top_level_1 (ignore=XIL(0)) at keyboard.c:1111
#34 0x0000000000697c09 in internal_catch (tag=XIL(0xe0d0), func=0x5c4a40 <top_level_1>, arg=XIL(0)) at eval.c:1198
#35 0x00000000005c4967 in command_loop () at keyboard.c:1072
#36 0x00000000005c3ec4 in recursive_edit_1 () at keyboard.c:720
#37 0x00000000005c40bc in Frecursive_edit () at keyboard.c:789
#38 0x00000000005bfb4b in main (argc=9, argv=0x7fffffffe368) at emacs.c:2297
Lisp Backtrace:
"load" (0xffffd570)
"let" (0xffffd6f0)
"while" (0xffffd8a0)
"let" (0xffffdac0)
"if" (0xffffdc40)
"normal-top-level" (0xffffde00)
(gdb)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Thu, 13 May 2021 14:45:01 GMT)
Full text and
rfc822 format available.
Message #217 received at 36649 <at> debbugs.gnu.org (full text, mbox):
On Wed, May 12, 2021 at 7:44 PM Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > I don't know if this is an interesting configuration. AFAIU,
> > "--with-dumping=none" means you run the CANNOT_DUMP version, which
> > doesn't dump Emacs at all.
>
> Ah, yes... and in that case I guess there is no pure space? Oh well, I
> guess somebody has to look into getting unexec working on Linux if we're
> to, er, see what the impact of pure space unexec would have been. If it
> was working. :-)
I had it working a while ago, just not using libc malloc(). AFAIU,
that's just incompatible with unexec() now.
(And it's still slightly but significantly faster building with
unexec() on Linux than building with pdumper, at least in contrived
benchmarks).
So, yes, I'd misunderstood Eli and thought he had objections to this
patch; if he doesn't, we should look into fixing the native-comp parts
and apply it :-)
Pip
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Thu, 13 May 2021 21:24:01 GMT)
Full text and
rfc822 format available.
Message #220 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Pip Cet <pipcet <at> gmail.com> writes:
> On Wed, May 12, 2021 at 7:44 PM Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > I don't know if this is an interesting configuration. AFAIU,
>> > "--with-dumping=none" means you run the CANNOT_DUMP version, which
>> > doesn't dump Emacs at all.
>>
>> Ah, yes... and in that case I guess there is no pure space? Oh well, I
>> guess somebody has to look into getting unexec working on Linux if we're
>> to, er, see what the impact of pure space unexec would have been. If it
>> was working. :-)
>
> I had it working a while ago, just not using libc malloc(). AFAIU,
> that's just incompatible with unexec() now.
>
> (And it's still slightly but significantly faster building with
> unexec() on Linux than building with pdumper, at least in contrived
> benchmarks).
>
> So, yes, I'd misunderstood Eli and thought he had objections to this
> patch; if he doesn't, we should look into fixing the native-comp parts
> and apply it :-)
Right, if you like me to have a look to the native-comp side would be
handy to have this patch pushed as a git branch on our repo.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Fri, 14 May 2021 06:27:01 GMT)
Full text and
rfc822 format available.
Message #223 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>,
> eggert <at> cs.ucla.edu, rpluim <at> gmail.com, stefan <at> marxist.se,
> schwab <at> linux-m68k.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
> 36649 <at> debbugs.gnu.org
> Date: Thu, 13 May 2021 21:23:10 +0000
>
> > So, yes, I'd misunderstood Eli and thought he had objections to this
> > patch; if he doesn't, we should look into fixing the native-comp parts
> > and apply it :-)
>
> Right, if you like me to have a look to the native-comp side would be
> handy to have this patch pushed as a git branch on our repo.
I'm not sure what native-comp has to do with this: AFAIK native-comp
doesn't support unexec at all, so any unexec build will not have
native compilation enabled.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Fri, 14 May 2021 06:37:02 GMT)
Full text and
rfc822 format available.
Message #226 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Andrea Corallo <akrl <at> sdf.org>
>> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>,
>> eggert <at> cs.ucla.edu, rpluim <at> gmail.com, stefan <at> marxist.se,
>> schwab <at> linux-m68k.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
>> 36649 <at> debbugs.gnu.org
>> Date: Thu, 13 May 2021 21:23:10 +0000
>>
>> > So, yes, I'd misunderstood Eli and thought he had objections to this
>> > patch; if he doesn't, we should look into fixing the native-comp parts
>> > and apply it :-)
>>
>> Right, if you like me to have a look to the native-comp side would be
>> handy to have this patch pushed as a git branch on our repo.
>
> I'm not sure what native-comp has to do with this: AFAIK native-comp
> doesn't support unexec at all, so any unexec build will not have
> native compilation enabled.
Yes is not unexec related, native comp classifies immediates that
originally went into pure space or not before hash consing then in order
to retain compatibility. We should just remove this distinction if we
remove pure space.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Fri, 14 May 2021 07:09:01 GMT)
Full text and
rfc822 format available.
Message #229 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: pipcet <at> gmail.com, larsi <at> gnus.org, eggert <at> cs.ucla.edu, rpluim <at> gmail.com,
> stefan <at> marxist.se, schwab <at> linux-m68k.org, monnier <at> iro.umontreal.ca,
> 36649 <at> debbugs.gnu.org
> Date: Fri, 14 May 2021 06:35:46 +0000
>
> > I'm not sure what native-comp has to do with this: AFAIK native-comp
> > doesn't support unexec at all, so any unexec build will not have
> > native compilation enabled.
>
> Yes is not unexec related, native comp classifies immediates that
> originally went into pure space or not before hash consing then in order
> to retain compatibility. We should just remove this distinction if we
> remove pure space.
Ah, okay. If you ask me, this is one more reason to wait with
removing the purespace. But that's me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sun, 16 May 2021 13:39:02 GMT)
Full text and
rfc822 format available.
Message #232 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Looks like some memory problem: xrealloc segfaults.
>
> Don't we need to disable ASLR for unexec to work? And doesn't that
> require setfattr or paxctl commands to be available? If not, how do
> we disable ASLR in bootstrap-emacs and emacs binaries on GNU/Linux?
Hm... the PROBLEMS file has this:
----
These segfaults should not occur on most modern systems, because the
Emacs build procedure uses the command 'setfattr' or 'paxctl' to mark
the Emacs executable as requiring non-randomized address space, and
Emacs uses the 'personality' system call to disable address space
randomization when dumping.
----
Is that correct? I thought we had ASLR switched on on GNU/Linux builds?
----
To work around the ASLR problem in either an older or a newer kernel,
you can temporarily disable the feature while building Emacs. On
GNU/Linux you can do so using the following command (as root).
echo 0 > /proc/sys/kernel/randomize_va_space
----
I tried this recipe now on Debian/bullseye, but the unexec build still
segfaults.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sun, 16 May 2021 13:47:01 GMT)
Full text and
rfc822 format available.
Message #235 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo <akrl <at> sdf.org> writes:
> Right, if you like me to have a look to the native-comp side would be
> handy to have this patch pushed as a git branch on our repo.
I've now pushed a new branch called scratch/no-purespace which has Pip's
patch with some merge fix-ups from me. It builds fine without
native-comp, but has many errors in comp.c if enabled. So feel free to
fix that up. :-)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Mon, 17 May 2021 08:44:02 GMT)
Full text and
rfc822 format available.
Message #238 received at 36649 <at> debbugs.gnu.org (full text, mbox):
On 5/16/21 6:38 AM, Lars Ingebrigtsen wrote:
> I thought we had ASLR switched on on GNU/Linux builds?
If unexec is used on GNU/Linux, Emacs is supposed to switch ASLR off by
using "setfattr -n user.pax.flags -v er temacs", and if that doesn't
work by using the personality syscall and then re-execing itself (see
maybe_disable_address_randomization).
I doubt whether it's worth spending much time debugging the problem,
since nobody uses unexec on GNU/Linux any more.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Mon, 17 May 2021 10:26:02 GMT)
Full text and
rfc822 format available.
Message #241 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> Cc: rpluim <at> gmail.com, stefan <at> marxist.se, schwab <at> linux-m68k.org,
> monnier <at> iro.umontreal.ca, pipcet <at> gmail.com, 36649 <at> debbugs.gnu.org,
> akrl <at> sdf.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Mon, 17 May 2021 01:43:31 -0700
>
> I doubt whether it's worth spending much time debugging the problem,
> since nobody uses unexec on GNU/Linux any more.
Since we decided not to remove unexec in Emacs 28, we do need to keep
the unexec configuration working. So I find it unfortunate that you
keep saying that, because the result is a direct contradiction of what
we decided.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Mon, 17 May 2021 14:14:02 GMT)
Full text and
rfc822 format available.
Message #244 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> If unexec is used on GNU/Linux, Emacs is supposed to switch ASLR off
> by using "setfattr -n user.pax.flags -v er temacs", and if that
> doesn't work by using the personality syscall and then re-execing
> itself (see maybe_disable_address_randomization).
Ah, thanks. My src/Makefile had
## If needed, the names of the paxctl and setfattr programs.
## On grsecurity/PaX systems, unexec will fail due to a gap between
## the bss section and the heap. Older versions need paxctl to work
## around this, newer ones setfattr. See Bug#11398 and Bug#16343.
PAXCTL =
SETFATTR =
## Commands to set PaX flags on dumped and not-dumped instances of Emacs.
PAXCTL_dumped =
PAXCTL_notdumped =
because the "attr" package wasn't installed, so there was no setfattr
executable.
(So if we want to continue supporting unexec, we should probably add
that as a configure requirement, perhaps.)
With that, Emacs now fails in a different way -- instead of segfaulting,
I get to:
make[2]: Entering directory '/home/larsi/src/emacs/xo/lisp'
ELC international/titdic-cnv.elc
corrupted double-linked list
Fatal error 6: Aborted
Backtrace:
../src/bootstrap-emacs[0x525571]
../src/bootstrap-emacs[0x4203b6]
../src/bootstrap-emacs[0x420889]
But as you say, debugging this is pretty much a waste of time.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Mon, 17 May 2021 14:17:02 GMT)
Full text and
rfc822 format available.
Message #247 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Since we decided not to remove unexec in Emacs 28, we do need to keep
> the unexec configuration working. So I find it unfortunate that you
> keep saying that, because the result is a direct contradiction of what
> we decided.
Well, if we decided something at one point, we can decide something else
now.
The question is whether it makes sense to spend time trying to fix
something that's not being used. Keeping unexec around in a broken
state isn't very satisfying, and worries about unexec is what's stalling
the removal of pure space, too.
So at this point I think I'd rather just remove unexec now instead of
waiting until Emacs 29.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Mon, 17 May 2021 14:25:01 GMT)
Full text and
rfc822 format available.
Message #250 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, rpluim <at> gmail.com, stefan <at> marxist.se,
> schwab <at> linux-m68k.org, monnier <at> iro.umontreal.ca, pipcet <at> gmail.com,
> 36649 <at> debbugs.gnu.org, akrl <at> sdf.org
> Date: Mon, 17 May 2021 16:15:46 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Since we decided not to remove unexec in Emacs 28, we do need to keep
> > the unexec configuration working. So I find it unfortunate that you
> > keep saying that, because the result is a direct contradiction of what
> > we decided.
>
> Well, if we decided something at one point, we can decide something else
> now.
We can, but we really shouldn't in this case. We never remove
obsolete features so quickly, and I see no reason to do this now.
> The question is whether it makes sense to spend time trying to fix
> something that's not being used. Keeping unexec around in a broken
> state isn't very satisfying, and worries about unexec is what's stalling
> the removal of pure space, too.
>
> So at this point I think I'd rather just remove unexec now instead of
> waiting until Emacs 29.
I see no reason for the rush, Emacs 28 is not around the corner
anyway. We have enough new and important features there that will
take us time to shake out all the bugs and stabilize the codebase.
If no one else is willing to debug the unexec problems, I will do it
myself, at my own pace. Just leave it to me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Mon, 17 May 2021 14:33:02 GMT)
Full text and
rfc822 format available.
Message #253 received at 36649 <at> debbugs.gnu.org (full text, mbox):
On Mai 17 2021, Lars Ingebrigtsen wrote:
> worries about unexec is what's stalling the removal of pure space,
> too.
unexec does not really depend on pure space.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Tue, 18 May 2021 13:34:01 GMT)
Full text and
rfc822 format available.
Message #256 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab <schwab <at> linux-m68k.org> writes:
> On Mai 17 2021, Lars Ingebrigtsen wrote:
>
>> worries about unexec is what's stalling the removal of pure space,
>> too.
>
> unexec does not really depend on pure space.
No, but Eli was worried that applying this patch would further
destabilise the unexec code, which I think is fair.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 19 May 2021 15:12:02 GMT)
Full text and
rfc822 format available.
Message #259 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 17 May 2021 17:23:50 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: eggert <at> cs.ucla.edu, rpluim <at> gmail.com, stefan <at> marxist.se,
> schwab <at> linux-m68k.org, monnier <at> iro.umontreal.ca, pipcet <at> gmail.com,
> 36649 <at> debbugs.gnu.org, akrl <at> sdf.org
>
> If no one else is willing to debug the unexec problems, I will do it
> myself, at my own pace.
Now done. At least the unoptimized build with unexec runs cleanly to
completion on GNU/Linux. Turns out we broke this about 1.5 year ago,
when an unrelated change inadvertently disabled the use of
HYBRID_MALLOC in this build, which is a must for unexec to work on
this platform.
There's one aspect of the changeset I pushed that I'm uneasy about.
It is this part in configure.ac:
diff --git a/configure.ac b/configure.ac
index 3df4359..d35ac6d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2306,6 +2309,9 @@ AC_DEFUN
GNU_MALLOC_reason=" (only before dumping)"
GMALLOC_OBJ=gmalloc.o
VMLIMIT_OBJ=
+ # FIXME: This is to prevent Gnulib from redirecting 'free' to its
+ # replacement, instead of 'hybrid_free' in gmalloc.c.
+ gl_cv_func_free_preserves_errno=yes
else
test "$doug_lea_malloc" != "yes" && GMALLOC_OBJ=gmalloc.o
VMLIMIT_OBJ=vm-limit.o
The problem here is that Gnulib wants to redirect 'free' to its
replacement 'rpl_free', and that breaks our own redirection, in
conf_post.h, to 'hybrid_free' (of gmalloc.c), which we _must_ use in
this configuration. I couldn't find a clean fix, so for now the
unexec build will not use the Gnulib replacement for 'free'.
Paul, if this kludge annoys you enough (I hope it will), please
suggest a cleaner way out of this conundrum.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 19 May 2021 17:30:02 GMT)
Full text and
rfc822 format available.
Message #262 received at 36649 <at> debbugs.gnu.org (full text, mbox):
On 5/19/21 8:11 AM, Eli Zaretskii wrote:
> Paul, if this kludge annoys you enough (I hope it will), please
> suggest a cleaner way out of this conundrum.
configure.ac can define a macro that tells gmalloc.c about the kludge
situation, and gmalloc.c can refer to that macro to decide whether to
call rpl_free instead of plain 'free'.
Also, make sure that hybrid_free preserves errno.
Without these fixes some Gnulib code will possibly stop working, since
the rest of Gnulib assumes 'free' preserves errno.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 19 May 2021 17:39:01 GMT)
Full text and
rfc822 format available.
Message #265 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> Cc: rpluim <at> gmail.com, stefan <at> marxist.se, schwab <at> linux-m68k.org,
> monnier <at> iro.umontreal.ca, 36649 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Wed, 19 May 2021 10:29:06 -0700
>
> On 5/19/21 8:11 AM, Eli Zaretskii wrote:
> > Paul, if this kludge annoys you enough (I hope it will), please
> > suggest a cleaner way out of this conundrum.
>
> configure.ac can define a macro that tells gmalloc.c about the kludge
> situation, and gmalloc.c can refer to that macro to decide whether to
> call rpl_free instead of plain 'free'.
The problem is not in gmalloc.c, the problem is in every src/*.c file
that calls 'free'. That's because we redirect to hybrid_free in
conf_post.h, but Gnulib's stdlib.h is included after that, and it
undoes that redirection:
#if @GNULIB_FREE_POSIX@
# if @REPLACE_FREE@
# if !(defined __cplusplus && defined GNULIB_NAMESPACE)
# undef free
# define free rpl_free
# endif
Then the linker errors out due to unresolved externals, because
there's no rpl_free.
Would it work to add rpl_free to gmalloc.c, perhaps?
> Also, make sure that hybrid_free preserves errno.
If this is the best solution, then okay, will do. I hoped something
cleaner could be possible.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 19 May 2021 17:44:02 GMT)
Full text and
rfc822 format available.
Message #268 received at 36649 <at> debbugs.gnu.org (full text, mbox):
On 5/19/21 10:38 AM, Eli Zaretskii wrote:
> The problem is not in gmalloc.c, the problem is in every src/*.c file
> that calls 'free'. That's because we redirect to hybrid_free in
> conf_post.h, but Gnulib's stdlib.h is included after that,
Have conf_post.h include stdlib.h before it redefines 'free'. It should
do that anyway, since POSIX stdlib.h is allowed to define 'free' as a macro.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 19 May 2021 18:56:01 GMT)
Full text and
rfc822 format available.
Message #271 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> If no one else is willing to debug the unexec problems, I will do it
>> myself, at my own pace.
>
> Now done. At least the unoptimized build with unexec runs cleanly to
> completion on GNU/Linux.
Yup; I can confirm that the following works here on this Debian/bullseye
system:
./configure --with-unexec=yes --with-dumping=unexec; make bootstrap
I'll try to get the previously discussed benchmarking done later this
week.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Thu, 20 May 2021 08:47:02 GMT)
Full text and
rfc822 format available.
Message #274 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> Cc: larsi <at> gnus.org, rpluim <at> gmail.com, stefan <at> marxist.se,
> schwab <at> linux-m68k.org, monnier <at> iro.umontreal.ca, 36649 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Wed, 19 May 2021 10:43:24 -0700
>
> On 5/19/21 10:38 AM, Eli Zaretskii wrote:
> > The problem is not in gmalloc.c, the problem is in every src/*.c file
> > that calls 'free'. That's because we redirect to hybrid_free in
> > conf_post.h, but Gnulib's stdlib.h is included after that,
>
> Have conf_post.h include stdlib.h before it redefines 'free'. It should
> do that anyway, since POSIX stdlib.h is allowed to define 'free' as a macro.
Thanks, this does work and looks much cleaner, so I've now made that
change.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 20 Oct 2021 17:42:01 GMT)
Full text and
rfc822 format available.
Message #277 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> I doubt whether it's worth spending much time debugging the problem,
>> since nobody uses unexec on GNU/Linux any more.
>
> Since we decided not to remove unexec in Emacs 28, we do need to keep
> the unexec configuration working.
Should we consider removing unexec in Emacs 29?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Wed, 20 Oct 2021 18:19:02 GMT)
Full text and
rfc822 format available.
Message #280 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Wed, 20 Oct 2021 10:41:28 -0700
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, rpluim <at> gmail.com, schwab <at> linux-m68k.org,
> monnier <at> iro.umontreal.ca, pipcet <at> gmail.com, 36649 <at> debbugs.gnu.org,
> larsi <at> gnus.org, akrl <at> sdf.org
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> I doubt whether it's worth spending much time debugging the problem,
> >> since nobody uses unexec on GNU/Linux any more.
> >
> > Since we decided not to remove unexec in Emacs 28, we do need to keep
> > the unexec configuration working.
>
> Should we consider removing unexec in Emacs 29?
That's possible, but we still have plenty of time before we get to the
decision point, and have no information at all regarding whether
unexec is still used with Emacs 28 (because it wasn't released yet).
So it's too early to make the decision, and we have no data on which
to base the decision.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Fri, 01 Jul 2022 13:47:01 GMT)
Full text and
rfc822 format available.
Message #283 received at 36649 <at> debbugs.gnu.org (full text, mbox):
I rebased the `scratch/no-purespace` on top of `master`.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Fri, 01 Jul 2022 15:52:01 GMT)
Full text and
rfc822 format available.
Message #286 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier [2022-07-01 09:46:10] wrote:
> I rebased the `scratch/no-purespace` on top of `master`.
It seems to work fine, both with pdump and with unexec (only tried
under Debian testing).
Should I clean it up and push it to `master`?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Fri, 01 Jul 2022 16:04:02 GMT)
Full text and
rfc822 format available.
Message #289 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> Cc: 36649 <at> debbugs.gnu.org
> Date: Fri, 01 Jul 2022 11:51:25 -0400
> From: Stefan Monnier via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> Stefan Monnier [2022-07-01 09:46:10] wrote:
> > I rebased the `scratch/no-purespace` on top of `master`.
>
> It seems to work fine, both with pdump and with unexec (only tried
> under Debian testing).
> Should I clean it up and push it to `master`?
Only for pdumper, I think. AFAIR, we didn't want to remove pure space
in the unexec build.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Fri, 01 Jul 2022 16:34:01 GMT)
Full text and
rfc822 format available.
Message #292 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> Only for pdumper, I think. AFAIR, we didn't want to remove pure space
> in the unexec build.
That means keeping purespace and hence not applying the patch.
Why would we want to keep purespace in the unexec build?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Fri, 01 Jul 2022 18:13:02 GMT)
Full text and
rfc822 format available.
Message #295 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: pipcet <at> gmail.com, 36649 <at> debbugs.gnu.org
> Date: Fri, 01 Jul 2022 12:33:13 -0400
>
> > Only for pdumper, I think. AFAIR, we didn't want to remove pure space
> > in the unexec build.
>
> That means keeping purespace and hence not applying the patch.
> Why would we want to keep purespace in the unexec build?
This was discussed at length, I think in this bug as well.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Fri, 01 Jul 2022 18:59:02 GMT)
Full text and
rfc822 format available.
Message #298 received at 36649 <at> debbugs.gnu.org (full text, mbox):
>> That means keeping purespace and hence not applying the patch.
>> Why would we want to keep purespace in the unexec build?
> This was discussed at length, I think in this bug as well.
I've seen it stated in this thread, but never explained, no.
The only "explanation" I've seen is quotes of me saying that it has
a performance impact (I guess it wasn't my brightest moment: it does
have a performance impact, but that impact is the same that's paid by
all users of the pdumper, so it can't be significant enough to stop
installing this patch).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sat, 02 Jul 2022 08:57:02 GMT)
Full text and
rfc822 format available.
Message #301 received at 36649 <at> debbugs.gnu.org (full text, mbox):
On Fri, Jul 1, 2022 at 6:58 PM Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
> >> That means keeping purespace and hence not applying the patch.
> >> Why would we want to keep purespace in the unexec build?
> > This was discussed at length, I think in this bug as well.
> I've seen it stated in this thread, but never explained, no.
FWIW, I don't recall any reason why it shouldn't work with unexec,
either. To the best of my recollection, unexec was generally broken at
the time I wrote the patch; I fixed unexec and then it worked without
purespace, but the unexec fixes never made it into master until Eli
re-did them a while later.
(IIRC, this patch predates the nativecomp merge and that affected pure
space a little, so that probably needs to be kept in mind.)
Pip
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sat, 02 Jul 2022 09:07:02 GMT)
Full text and
rfc822 format available.
Message #304 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Pip Cet <pipcet <at> gmail.com>
> Date: Sat, 2 Jul 2022 08:55:46 +0000
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 36649 <at> debbugs.gnu.org
>
> On Fri, Jul 1, 2022 at 6:58 PM Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
> > >> That means keeping purespace and hence not applying the patch.
> > >> Why would we want to keep purespace in the unexec build?
> > > This was discussed at length, I think in this bug as well.
> > I've seen it stated in this thread, but never explained, no.
>
> FWIW, I don't recall any reason why it shouldn't work with unexec,
> either. To the best of my recollection, unexec was generally broken at
> the time I wrote the patch; I fixed unexec and then it worked without
> purespace, but the unexec fixes never made it into master until Eli
> re-did them a while later.
Basically, I don't want us to drop the pure space in the unexec
builds, whether it makes sense to the rest of you or not. So there
are two alternatives: either drop pure space only for the pdumper
build, or wait for us to remove the unexec support and drop pure space
then.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sat, 02 Jul 2022 09:17:02 GMT)
Full text and
rfc822 format available.
Message #307 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Basically, I don't want us to drop the pure space in the unexec
> builds, whether it makes sense to the rest of you or not.
Could you explain why? Skimming this thread, I must have missed the
rationale. (But it's a long thread.)
> So there are two alternatives: either drop pure space only for the
> pdumper build, or wait for us to remove the unexec support and drop
> pure space then.
If I understand correctly, dropping pure space would make Po's work on
improving the garbage collector easier -- and improving gc is important,
so it seems to make sense to get rid of pure space just for that reason.
But I'm not against dropping unexec now, too -- we can drop both unexec
and pure space now.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sat, 02 Jul 2022 09:23:02 GMT)
Full text and
rfc822 format available.
Message #310 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Pip Cet <pipcet <at> gmail.com>, 36649 <at> debbugs.gnu.org,
> monnier <at> iro.umontreal.ca, Po Lu <luangruo <at> yahoo.com>
> Date: Sat, 02 Jul 2022 11:16:05 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Basically, I don't want us to drop the pure space in the unexec
> > builds, whether it makes sense to the rest of you or not.
>
> Could you explain why?
Because I don't want to invest any significant effort in maintaining
the unexec build. It should remain as close to its original shape as
possible, until it's gone.
> > So there are two alternatives: either drop pure space only for the
> > pdumper build, or wait for us to remove the unexec support and drop
> > pure space then.
>
> If I understand correctly, dropping pure space would make Po's work on
> improving the garbage collector easier -- and improving gc is important,
> so it seems to make sense to get rid of pure space just for that reason.
He said he already dropped that in the branch where he works, so that
is AFAIU a moot point. (And if he didn't drop it already, he can drop
it now in that branch.)
> But I'm not against dropping unexec now, too -- we can drop both unexec
> and pure space now.
Not yet, we don't have enough experience without it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sat, 02 Jul 2022 10:29:01 GMT)
Full text and
rfc822 format available.
Message #313 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> If I understand correctly, dropping pure space would make Po's work on
> improving the garbage collector easier -- and improving gc is important,
> so it seems to make sense to get rid of pure space just for that reason.
>
> But I'm not against dropping unexec now, too -- we can drop both unexec
> and pure space now.
FWIW none of the dumping mechanisms work with the new garbage collector,
but it will be optional, since I don't see how to make it work on MS-DOS
(which AFAIU has no equivalent of `mprotect'). The current
implementation also assumes 4K pages.
So in my work, pure space and incremental GC are both conditional, under
#ifdef HAVE_MPROTECT.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sat, 02 Jul 2022 10:31:01 GMT)
Full text and
rfc822 format available.
Message #316 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Not yet, we don't have enough experience without it.
Not to mention that the pdumper currently doesn't work on Windows 9x,
MS-DOS, and GNU/Linux on m68k.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sat, 02 Jul 2022 10:34:02 GMT)
Full text and
rfc822 format available.
Message #319 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Po Lu <luangruo <at> yahoo.com> writes:
> FWIW none of the dumping mechanisms work with the new garbage collector,
> but it will be optional, since I don't see how to make it work on MS-DOS
> (which AFAIU has no equivalent of `mprotect'). The current
> implementation also assumes 4K pages.
>
> So in my work, pure space and incremental GC are both conditional, under
> #ifdef HAVE_MPROTECT.
Sorry, I meant pure space is conditional when not HAVE_MPROTECT, while
incremental GC is enabled when it is defined. Or rather, will be, since
so far I've only made blind, half hearted attempts to keep the regular
GC building. It probably won't build or work.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sat, 02 Jul 2022 10:41:02 GMT)
Full text and
rfc822 format available.
Message #322 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Pip Cet <pipcet <at> gmail.com>,
> 36649 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> Date: Sat, 02 Jul 2022 18:28:40 +0800
>
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
> > If I understand correctly, dropping pure space would make Po's work on
> > improving the garbage collector easier -- and improving gc is important,
> > so it seems to make sense to get rid of pure space just for that reason.
> >
> > But I'm not against dropping unexec now, too -- we can drop both unexec
> > and pure space now.
>
> FWIW none of the dumping mechanisms work with the new garbage collector,
> but it will be optional, since I don't see how to make it work on MS-DOS
> (which AFAIU has no equivalent of `mprotect').
The C library and the environment used by the MS-DOS port do have
mprotect, but it is only supported with some DPMI servers, and the
MS-Windows DPMI server is not one of them.
But I don't think this is too relevant, since memory protection in
MS-DOS is more or less a no-op.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sat, 02 Jul 2022 10:42:01 GMT)
Full text and
rfc822 format available.
Message #325 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, pipcet <at> gmail.com,
> 36649 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> Date: Sat, 02 Jul 2022 18:30:10 +0800
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Not yet, we don't have enough experience without it.
>
> Not to mention that the pdumper currently doesn't work on Windows 9x,
> MS-DOS, and GNU/Linux on m68k.
The latter case is the reason why we cannot yet remove unexec.
Is m68k a live platform, or is it also dying?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sat, 02 Jul 2022 10:52:01 GMT)
Full text and
rfc822 format available.
Message #328 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> The latter case is the reason why we cannot yet remove unexec.
>
> Is m68k a live platform, or is it also dying?
It's still supported by at least one major GNU/Linux distribution, and
there was recent activity on bug#44531, so it's still being used enough
for users to complain when something goes wrong.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sat, 02 Jul 2022 10:56:02 GMT)
Full text and
rfc822 format available.
Message #331 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> The C library and the environment used by the MS-DOS port do have
> mprotect, but it is only supported with some DPMI servers, and the
> MS-Windows DPMI server is not one of them.
Too bad. That means MS-DOS will have to do with the old garbage
collector.
> But I don't think this is too relevant, since memory protection in
> MS-DOS is more or less a no-op.
For incremental garbage collection to work, Emacs needs to be able to
place memory protection on "blocks" of objects allocated to align with a
page start, in order to receive a signal when a write to an object in
such a block happens.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sat, 02 Jul 2022 12:08:02 GMT)
Full text and
rfc822 format available.
Message #334 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Po Lu <luangruo <at> yahoo.com> writes:
>> The latter case is the reason why we cannot yet remove unexec.
>>
>> Is m68k a live platform, or is it also dying?
>
> It's still supported by at least one major GNU/Linux distribution, and
> there was recent activity on bug#44531, so it's still being used enough
> for users to complain when something goes wrong.
Which GNU/Linux distribution is that?
Anyway, I don't feel that carrying around unexec just for m68k is
warranted -- it's a super duper marginal platform, and probably isn't
used for real work by anybody. (So they can use older Emacs versions if
they absolutely have to.)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sat, 02 Jul 2022 12:23:02 GMT)
Full text and
rfc822 format available.
Message #337 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Which GNU/Linux distribution is that?
The reporter used Debian.
> Anyway, I don't feel that carrying around unexec just for m68k is
> warranted -- it's a super duper marginal platform, and probably isn't
> used for real work by anybody. (So they can use older Emacs versions if
> they absolutely have to.)
unexec isn't doing any harm by itself, so there's no reason to not keep
it. I don't forsee much trouble in keeping pure space behind a few
ifdefs; it should be a mostly mechanical job.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sat, 02 Jul 2022 12:42:01 GMT)
Full text and
rfc822 format available.
Message #340 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Po Lu <luangruo <at> yahoo.com> writes:
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>> Which GNU/Linux distribution is that?
>
> The reporter used Debian.
According to:
https://www.debian.org/ports/m68k/
The Debian m68k port was first officially released with Debian 2.0
(hamm) and was an official port until Debian 4.0 (etch). There's now
an effort to revive this port.
Debian 4.0 was over a decade ago, so either they were using Debian from
2010, or they're part of the effort to revive the port.
Hm... Ah!
https://buildd.debian.org/status/fetch.php?pkg=emacs&arch=m68k&ver=1%3A27.1%2B1-3&stamp=1604857999&raw=0
This isn't a report from somebody using Emacs on m68k, but a Debian
developer trying to revive the port. (Which has not happened.)
So it seems safe to assume that nobody uses Emacs on m68k.
>> Anyway, I don't feel that carrying around unexec just for m68k is
>> warranted -- it's a super duper marginal platform, and probably isn't
>> used for real work by anybody. (So they can use older Emacs versions if
>> they absolutely have to.)
>
> unexec isn't doing any harm by itself, so there's no reason to not keep
> it. I don't forsee much trouble in keeping pure space behind a few
> ifdefs; it should be a mostly mechanical job.
But Eli doesn't want to get rid of purespace (which we do want to) until
we get rid of unexec, so unexec is blocking progress in that sense.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sat, 02 Jul 2022 12:46:02 GMT)
Full text and
rfc822 format available.
Message #343 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, pipcet <at> gmail.com, 36649 <at> debbugs.gnu.org,
> monnier <at> iro.umontreal.ca
> Date: Sat, 02 Jul 2022 14:41:01 +0200
>
> > unexec isn't doing any harm by itself, so there's no reason to not keep
> > it. I don't forsee much trouble in keeping pure space behind a few
> > ifdefs; it should be a mostly mechanical job.
>
> But Eli doesn't want to get rid of purespace (which we do want to) until
> we get rid of unexec, so unexec is blocking progress in that sense.
No, I'm okay with having the purespace removed from the pdumper
builds, if the unexec build can still use it. AFAIU, that's the
"behind several ifdefs" alternative.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sat, 02 Jul 2022 16:58:02 GMT)
Full text and
rfc822 format available.
Message #346 received at 36649 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> > Basically, I don't want us to drop the pure space in the unexec
>> > builds, whether it makes sense to the rest of you or not.
>> Could you explain why?
> Because I don't want to invest any significant effort in maintaining
> the unexec build.
The patch does not touch the unexec code at all.
If anything, it should make unexec simpler to maintain, since there's
one less issue to worry about (the current code might have to worry
about dumping the normal heap plus the purespace, whereas the new code
only has to worry about the normal heap), but `grep -i pur src/unex*.c`
suggests that the purespace has never had any impact on unexec.
> No, I'm okay with having the purespace removed from the pdumper
> builds, if the unexec build can still use it. AFAIU, that's the
> "behind several ifdefs" alternative.
I don't know how to remove the purespace in pdump builds and not in
unexec builds. I don't even know what that would mean and/or look like.
Would the patch below be acceptable?
Stefan
[purespace.diff (text/x-diff, inline)]
commit 3daf833ff3f3e99b44731808cb197c0912649997
Author: Stefan Monnier <monnier <at> iro.umontreal.ca>
Date: Fri Jul 1 14:36:49 2022 -0400
src/alloc.c: Remove all uses of `pure_alloc`
First step of removal of the purespace: stop using it.
The more delicate parts are the handling of 0-length strings and
vectors which we used to allocate in purespace but now need to be
allocated elsewhere, but the existing code makes us work harder to
allocate them in the normal way.
* src/alloc.c: Remove all uses of `pure_alloc`.
(init_strings): Alloc empty strings in the normal heap.
(init_vectors): Allocate the zero_vector in the normal heap.
(make_pure_string, make_pure_c_string, pure_cons): Rewrite to create
normal heap objects.
(find_string_data_in_pure, make_pure_float, make_pure_bignum)
(make_pure_vector, purecopy_hash_table): Delete functions.
(purecopy): Return without purecopying.
diff --git a/src/alloc.c b/src/alloc.c
index f115a3cebaa..522547661a5 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -435,7 +435,6 @@ no_sanitize_memcpy (void *dest, void const *src, size_t size)
static void unchain_finalizer (struct Lisp_Finalizer *);
static void mark_terminals (void);
static void gc_sweep (void);
-static Lisp_Object make_pure_vector (ptrdiff_t);
static void mark_buffer (struct buffer *);
#if !defined REL_ALLOC || defined SYSTEM_MALLOC || defined HYBRID_MALLOC
@@ -1674,12 +1673,30 @@ #define GC_STRING_EXTRA GC_STRING_OVERRUN_COOKIE_SIZE
/* Initialize string allocation. Called from init_alloc_once. */
+static struct Lisp_String *allocate_string (void);
+static void
+allocate_string_data (struct Lisp_String *s,
+ EMACS_INT nchars, EMACS_INT nbytes, bool clearit,
+ bool immovable);
+
static void
init_strings (void)
{
- empty_unibyte_string = make_pure_string ("", 0, 0, 0);
+ /* String allocation code will return one of 'empty_*ibyte_string'
+ when asked to construct a new 0-length string, so in order to build
+ those special cases, we have to do it "by hand". */
+ struct Lisp_String *ems = allocate_string ();
+ struct Lisp_String *eus = allocate_string ();
+ ems->u.s.intervals = NULL;
+ eus->u.s.intervals = NULL;
+ allocate_string_data (ems, 0, 0, false, false);
+ allocate_string_data (eus, 0, 0, false, false);
+ /* We can't use 'STRING_SET_UNIBYTE' because this one includes a hack
+ * to redirect its arg to 'empty_unibyte_string' when nbytes == 0. */
+ eus->u.s.size_byte = -1;
+ XSETSTRING (empty_multibyte_string, ems);
+ XSETSTRING (empty_unibyte_string, eus);
staticpro (&empty_unibyte_string);
- empty_multibyte_string = make_pure_string ("", 0, 0, 1);
staticpro (&empty_multibyte_string);
}
@@ -3008,12 +3025,25 @@ allocate_vector_block (void)
return block;
}
+static struct Lisp_Vector *
+allocate_vector_from_block (ptrdiff_t nbytes);
+
/* Called once to initialize vector allocation. */
static void
init_vectors (void)
{
- zero_vector = make_pure_vector (0);
+ /* The normal vector allocation code refuses to allocate a 0-length vector
+ because we use the first field of vectors internally when they're on
+ the free list, so we can't put a zero-length vector on the free list.
+ This is not a problem for 'zero_vector' since it's always reachable.
+ An alternative approach would be to allocate zero_vector outside of the
+ normal heap, e.g. as a static object, and then to "hide" it from the GC,
+ for example by marking it by hand at the beginning of the GC and unmarking
+ it by hand at the end. */
+ struct Lisp_Vector *zv = allocate_vector_from_block (vroundup (header_size));
+ zv->header.size = 0;
+ zero_vector = make_lisp_ptr (zv, Lisp_Vectorlike);
staticpro (&zero_vector);
}
@@ -5371,72 +5401,6 @@ check_pure_size (void)
#endif
-/* Find the byte sequence {DATA[0], ..., DATA[NBYTES-1], '\0'} from
- the non-Lisp data pool of the pure storage, and return its start
- address. Return NULL if not found. */
-
-static char *
-find_string_data_in_pure (const char *data, ptrdiff_t nbytes)
-{
- int i;
- ptrdiff_t skip, bm_skip[256], last_char_skip, infinity, start, start_max;
- const unsigned char *p;
- char *non_lisp_beg;
-
- if (pure_bytes_used_non_lisp <= nbytes)
- return NULL;
-
- /* Set up the Boyer-Moore table. */
- skip = nbytes + 1;
- for (i = 0; i < 256; i++)
- bm_skip[i] = skip;
-
- p = (const unsigned char *) data;
- while (--skip > 0)
- bm_skip[*p++] = skip;
-
- last_char_skip = bm_skip['\0'];
-
- non_lisp_beg = purebeg + pure_size - pure_bytes_used_non_lisp;
- start_max = pure_bytes_used_non_lisp - (nbytes + 1);
-
- /* See the comments in the function `boyer_moore' (search.c) for the
- use of `infinity'. */
- infinity = pure_bytes_used_non_lisp + 1;
- bm_skip['\0'] = infinity;
-
- p = (const unsigned char *) non_lisp_beg + nbytes;
- start = 0;
- do
- {
- /* Check the last character (== '\0'). */
- do
- {
- start += bm_skip[*(p + start)];
- }
- while (start <= start_max);
-
- if (start < infinity)
- /* Couldn't find the last character. */
- return NULL;
-
- /* No less than `infinity' means we could find the last
- character at `p[start - infinity]'. */
- start -= infinity;
-
- /* Check the remaining characters. */
- if (memcmp (data, non_lisp_beg + start, nbytes) == 0)
- /* Found. */
- return non_lisp_beg + start;
-
- start += last_char_skip;
- }
- while (start <= start_max);
-
- return NULL;
-}
-
-
/* Return a string allocated in pure space. DATA is a buffer holding
NCHARS characters, and NBYTES bytes of string data. MULTIBYTE
means make the result string multibyte.
@@ -5449,20 +5413,10 @@ find_string_data_in_pure (const char *data, ptrdiff_t nbytes)
make_pure_string (const char *data,
ptrdiff_t nchars, ptrdiff_t nbytes, bool multibyte)
{
- Lisp_Object string;
- struct Lisp_String *s = pure_alloc (sizeof *s, Lisp_String);
- s->u.s.data = (unsigned char *) find_string_data_in_pure (data, nbytes);
- if (s->u.s.data == NULL)
- {
- s->u.s.data = pure_alloc (nbytes + 1, -1);
- memcpy (s->u.s.data, data, nbytes);
- s->u.s.data[nbytes] = '\0';
- }
- s->u.s.size = nchars;
- s->u.s.size_byte = multibyte ? nbytes : -1;
- s->u.s.intervals = NULL;
- XSETSTRING (string, s);
- return string;
+ if (multibyte)
+ return make_multibyte_string (data, nchars, nbytes);
+ else
+ return make_unibyte_string (data, nchars);
}
/* Return a string allocated in pure space. Do not
@@ -5471,14 +5425,7 @@ make_pure_string (const char *data,
Lisp_Object
make_pure_c_string (const char *data, ptrdiff_t nchars)
{
- Lisp_Object string;
- struct Lisp_String *s = pure_alloc (sizeof *s, Lisp_String);
- s->u.s.size = nchars;
- s->u.s.size_byte = -2;
- s->u.s.data = (unsigned char *) data;
- s->u.s.intervals = NULL;
- XSETSTRING (string, s);
- return string;
+ return make_unibyte_string (data, nchars);
}
static Lisp_Object purecopy (Lisp_Object obj);
@@ -5489,103 +5436,10 @@ make_pure_c_string (const char *data, ptrdiff_t nchars)
Lisp_Object
pure_cons (Lisp_Object car, Lisp_Object cdr)
{
- Lisp_Object new;
- struct Lisp_Cons *p = pure_alloc (sizeof *p, Lisp_Cons);
- XSETCONS (new, p);
- XSETCAR (new, purecopy (car));
- XSETCDR (new, purecopy (cdr));
- return new;
+ return Fcons (car, cdr);
}
-/* Value is a float object with value NUM allocated from pure space. */
-
-static Lisp_Object
-make_pure_float (double num)
-{
- Lisp_Object new;
- struct Lisp_Float *p = pure_alloc (sizeof *p, Lisp_Float);
- XSETFLOAT (new, p);
- XFLOAT_INIT (new, num);
- return new;
-}
-
-/* Value is a bignum object with value VALUE allocated from pure
- space. */
-
-static Lisp_Object
-make_pure_bignum (Lisp_Object value)
-{
- mpz_t const *n = xbignum_val (value);
- size_t i, nlimbs = mpz_size (*n);
- size_t nbytes = nlimbs * sizeof (mp_limb_t);
- mp_limb_t *pure_limbs;
- mp_size_t new_size;
-
- struct Lisp_Bignum *b = pure_alloc (sizeof *b, Lisp_Vectorlike);
- XSETPVECTYPESIZE (b, PVEC_BIGNUM, 0, VECSIZE (struct Lisp_Bignum));
-
- int limb_alignment = alignof (mp_limb_t);
- pure_limbs = pure_alloc (nbytes, - limb_alignment);
- for (i = 0; i < nlimbs; ++i)
- pure_limbs[i] = mpz_getlimbn (*n, i);
-
- new_size = nlimbs;
- if (mpz_sgn (*n) < 0)
- new_size = -new_size;
-
- mpz_roinit_n (b->value, pure_limbs, new_size);
-
- return make_lisp_ptr (b, Lisp_Vectorlike);
-}
-
-/* Return a vector with room for LEN Lisp_Objects allocated from
- pure space. */
-
-static Lisp_Object
-make_pure_vector (ptrdiff_t len)
-{
- Lisp_Object new;
- size_t size = header_size + len * word_size;
- struct Lisp_Vector *p = pure_alloc (size, Lisp_Vectorlike);
- XSETVECTOR (new, p);
- XVECTOR (new)->header.size = len;
- return new;
-}
-
-/* Copy all contents and parameters of TABLE to a new table allocated
- from pure space, return the purified table. */
-static struct Lisp_Hash_Table *
-purecopy_hash_table (struct Lisp_Hash_Table *table)
-{
- eassert (NILP (table->weak));
- eassert (table->purecopy);
-
- struct Lisp_Hash_Table *pure = pure_alloc (sizeof *pure, Lisp_Vectorlike);
- struct hash_table_test pure_test = table->test;
-
- /* Purecopy the hash table test. */
- pure_test.name = purecopy (table->test.name);
- pure_test.user_hash_function = purecopy (table->test.user_hash_function);
- pure_test.user_cmp_function = purecopy (table->test.user_cmp_function);
-
- pure->header = table->header;
- pure->weak = purecopy (Qnil);
- pure->hash = purecopy (table->hash);
- pure->next = purecopy (table->next);
- pure->index = purecopy (table->index);
- pure->count = table->count;
- pure->next_free = table->next_free;
- pure->purecopy = table->purecopy;
- eassert (!pure->mutable);
- pure->rehash_threshold = table->rehash_threshold;
- pure->rehash_size = table->rehash_size;
- pure->key_and_value = purecopy (table->key_and_value);
- pure->test = pure_test;
-
- return pure;
-}
-
DEFUN ("purecopy", Fpurecopy, Spurecopy, 1, 1, 0,
doc: /* Make a copy of object OBJ in pure storage.
Recursively copies contents of vectors and cons cells.
@@ -5616,10 +5470,6 @@ purecopy (Lisp_Object obj)
|| SUBRP (obj))
return obj; /* Already pure. */
- if (STRINGP (obj) && XSTRING (obj)->u.s.intervals)
- message_with_string ("Dropping text-properties while making string `%s' pure",
- obj, true);
-
if (HASH_TABLE_P (Vpurify_flag)) /* Hash consing. */
{
Lisp_Object tmp = Fgethash (obj, Vpurify_flag, Qnil);
@@ -5627,74 +5477,6 @@ purecopy (Lisp_Object obj)
return tmp;
}
- if (CONSP (obj))
- obj = pure_cons (XCAR (obj), XCDR (obj));
- else if (FLOATP (obj))
- obj = make_pure_float (XFLOAT_DATA (obj));
- else if (STRINGP (obj))
- obj = make_pure_string (SSDATA (obj), SCHARS (obj),
- SBYTES (obj),
- STRING_MULTIBYTE (obj));
- else if (HASH_TABLE_P (obj))
- {
- struct Lisp_Hash_Table *table = XHASH_TABLE (obj);
- /* Do not purify hash tables which haven't been defined with
- :purecopy as non-nil or are weak - they aren't guaranteed to
- not change. */
- if (!NILP (table->weak) || !table->purecopy)
- {
- /* Instead, add the hash table to the list of pinned objects,
- so that it will be marked during GC. */
- struct pinned_object *o = xmalloc (sizeof *o);
- o->object = obj;
- o->next = pinned_objects;
- pinned_objects = o;
- return obj; /* Don't hash cons it. */
- }
-
- struct Lisp_Hash_Table *h = purecopy_hash_table (table);
- XSET_HASH_TABLE (obj, h);
- }
- else if (COMPILEDP (obj) || VECTORP (obj) || RECORDP (obj))
- {
- struct Lisp_Vector *objp = XVECTOR (obj);
- ptrdiff_t nbytes = vector_nbytes (objp);
- struct Lisp_Vector *vec = pure_alloc (nbytes, Lisp_Vectorlike);
- register ptrdiff_t i;
- ptrdiff_t size = ASIZE (obj);
- if (size & PSEUDOVECTOR_FLAG)
- size &= PSEUDOVECTOR_SIZE_MASK;
- memcpy (vec, objp, nbytes);
- for (i = 0; i < size; i++)
- vec->contents[i] = purecopy (vec->contents[i]);
- // Byte code strings must be pinned.
- if (COMPILEDP (obj) && size >= 2 && STRINGP (vec->contents[1])
- && !STRING_MULTIBYTE (vec->contents[1]))
- pin_string (vec->contents[1]);
- XSETVECTOR (obj, vec);
- }
- else if (BARE_SYMBOL_P (obj))
- {
- if (!XBARE_SYMBOL (obj)->u.s.pinned && !c_symbol_p (XBARE_SYMBOL (obj)))
- { /* We can't purify them, but they appear in many pure objects.
- Mark them as `pinned' so we know to mark them at every GC cycle. */
- XBARE_SYMBOL (obj)->u.s.pinned = true;
- symbol_block_pinned = symbol_block;
- }
- /* Don't hash-cons it. */
- return obj;
- }
- else if (BIGNUMP (obj))
- obj = make_pure_bignum (obj);
- else
- {
- AUTO_STRING (fmt, "Don't know how to purify: %S");
- Fsignal (Qerror, list1 (CALLN (Fformat, fmt, obj)));
- }
-
- if (HASH_TABLE_P (Vpurify_flag)) /* Hash consing. */
- Fputhash (obj, obj, Vpurify_flag);
-
return obj;
}
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sat, 02 Jul 2022 17:12:01 GMT)
Full text and
rfc822 format available.
Message #349 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, pipcet <at> gmail.com,
> 36649 <at> debbugs.gnu.org, luangruo <at> yahoo.com
> Date: Sat, 02 Jul 2022 12:57:09 -0400
>
> >> > Basically, I don't want us to drop the pure space in the unexec
> >> > builds, whether it makes sense to the rest of you or not.
> >> Could you explain why?
> > Because I don't want to invest any significant effort in maintaining
> > the unexec build.
>
> The patch does not touch the unexec code at all.
It "touches" the unexec code in that it removes purespace, and thus
changes the behavior of the unexec build. I don't want to deal with
consequences of such a change.
> If anything, it should make unexec simpler to maintain, since there's
> one less issue to worry about (the current code might have to worry
> about dumping the normal heap plus the purespace, whereas the new code
> only has to worry about the normal heap), but `grep -i pur src/unex*.c`
> suggests that the purespace has never had any impact on unexec.
I'm not convinced, sorry.
> > No, I'm okay with having the purespace removed from the pdumper
> > builds, if the unexec build can still use it. AFAIU, that's the
> > "behind several ifdefs" alternative.
>
> I don't know how to remove the purespace in pdump builds and not in
> unexec builds. I don't even know what that would mean and/or look
> like.
Po Lu said it should be simple, so maybe he will propose a patch?
> Would the patch below be acceptable?
No, because it removes purespace unconditionally.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sat, 02 Jul 2022 17:24:02 GMT)
Full text and
rfc822 format available.
Message #352 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> No, I'm okay with having the purespace removed from the pdumper
> builds, if the unexec build can still use it. AFAIU, that's the
> "behind several ifdefs" alternative.
One reason to get rid of pure space is to get rid of all the calls to
build_pure_c_string etc etc that litter the code, but just disabling
pure space in pdump doesn't help us with that. (And the reason we want
to do that is to make the code easier to approach for people.)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sat, 02 Jul 2022 17:33:02 GMT)
Full text and
rfc822 format available.
Message #355 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: luangruo <at> yahoo.com, pipcet <at> gmail.com, 36649 <at> debbugs.gnu.org,
> monnier <at> iro.umontreal.ca
> Date: Sat, 02 Jul 2022 19:23:24 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > No, I'm okay with having the purespace removed from the pdumper
> > builds, if the unexec build can still use it. AFAIU, that's the
> > "behind several ifdefs" alternative.
>
> One reason to get rid of pure space is to get rid of all the calls to
> build_pure_c_string etc etc that litter the code, but just disabling
> pure space in pdump doesn't help us with that. (And the reason we want
> to do that is to make the code easier to approach for people.)
Yes, I understand that this change has 2 parts: the syntactic part
(removing the calls to *pure* functions from our sources) and the part
that removes the use of purespace. The first part will have to wait
until we remove the unexec support; the second part can either wait
till then, or we can stop using purespace in the pdumper builds now.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sat, 02 Jul 2022 18:04:02 GMT)
Full text and
rfc822 format available.
Message #358 received at 36649 <at> debbugs.gnu.org (full text, mbox):
>> Would the patch below be acceptable?
> No, because it removes purespace unconditionally.
It does not remove purespace, it just stops using it.
IOW, it seems to match your description:
> until we remove the unexec support; the second part can either wait
> till then, or we can stop using purespace in the pdumper builds now.
Stfean
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sat, 02 Jul 2022 18:33:02 GMT)
Full text and
rfc822 format available.
Message #361 received at 36649 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: larsi <at> gnus.org, pipcet <at> gmail.com, 36649 <at> debbugs.gnu.org,
> luangruo <at> yahoo.com
> Date: Sat, 02 Jul 2022 14:03:29 -0400
>
> >> Would the patch below be acceptable?
> > No, because it removes purespace unconditionally.
>
> It does not remove purespace, it just stops using it.
It does that in all builds. Which is not what I agreed to. The
unexec build should continue using the purespace.
Severity set to 'wishlist' from 'normal'
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org.
(Sat, 02 Jul 2022 22:01:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sun, 03 Jul 2022 07:15:02 GMT)
Full text and
rfc822 format available.
Message #366 received at 36649 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> FWIW none of the dumping mechanisms work with the new garbage collector,
Interesting!
Is there something I could read about your new GC?
I'm asking because I once also had plans to rewrite Emacs' GC (to be incremental and generational). But hat was >20 years ago, and it never took off because the algorithm I used was patented. Which it no longer is, I think.
CC'ing Stefan because he reminded me of this, recently.
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sun, 03 Jul 2022 07:44:02 GMT)
Full text and
rfc822 format available.
Message #369 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Interesting!
>
> Is there something I could read about your new GC?
Not exactly. It's a very simple 3 color incremental mark-and-sweep
collector (which is not generational or moving) using hardware write
barriers to keep track of changes made by the mutator. I tried to keep
the design of the existing garbage collector intact as much as possible.
The motive was to get rid of the noticeable freeze during garbage
collection instead of making GC itself fast.
> I'm asking because I once also had plans to rewrite Emacs' GC (to be
> incremental and generational). But hat was >20 years ago, and it
> never took off because the algorithm I used was patented. Which it no
> longer is, I think.
Which algorithm(s) were you considering? I think that information might
be useful.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sun, 03 Jul 2022 08:22:02 GMT)
Full text and
rfc822 format available.
Message #372 received at 36649 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> On 2022-07-03,, at 9:42 , Po Lu <luangruo <at> yahoo.com> wrote:
>
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Interesting!
>>
>> Is there something I could read about your new GC?
>
> Not exactly. It's a very simple 3 color incremental mark-and-sweep
> collector (which is not generational or moving) using hardware write
> barriers to keep track of changes made by the mutator. I tried to keep
> the design of the existing garbage collector intact as much as possible.
I understand. I think I know the 3-color algorithm. Details don't matter that much.
>
> Which algorithm(s) were you considering? I think that information might
> be useful.
It's a mostly-copying GC, using VM pages and VM page protection. The mostly-copying part was patented at the time, which I noticed too late. AFAIU, that patent has expired, but that's a question for someone knowing US law better than me.
I can send you a C file if you want (also everyone else who wants it). Stefan already has it. I sent it around in 2001 or so, in the hope that it might be of some use in the future.
The C file even has some large explanatory comments, albeit I have to admit I wrote them years after the code, for sending it out.
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sun, 03 Jul 2022 09:39:02 GMT)
Full text and
rfc822 format available.
Message #375 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> I understand. I think I know the 3-color algorithm. Details don't
> matter that much.
Thanks.
> I can send you a C file if you want (also everyone else who wants it).
> Stefan already has it. I sent it around in 2001 or so, in the hope
> that it might be of some use in the future.
>
> The C file even has some large explanatory comments, albeit I have to
> admit I wrote them years after the code, for sending it out.
Sure, that would be useful. You're not the only person who has tried to
rewrite the garbage collector: Daniel Colascione recently took a stab at
a similar garbage collector too.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sun, 03 Jul 2022 09:43:02 GMT)
Full text and
rfc822 format available.
Message #378 received at 36649 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> On 2022-07-03,, at 11:38 , Po Lu <luangruo <at> yahoo.com> wrote:
>
> Sure, that would be useful.
Sent off-list.
> You're not the only person who has tried to
> rewrite the garbage collector: Daniel Colascione recently took a stab at
> a similar garbage collector too.
Can I ask what the result was? Is he still working on it?
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36649; Package
emacs.
(Sun, 03 Jul 2022 10:02:01 GMT)
Full text and
rfc822 format available.
Message #381 received at 36649 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Can I ask what the result was? Is he still working on it?
I think he doesn't have the time to continue working on it, so no, it's
not being worked on anymore.
Reply sent
to
Pip Cet <pipcet <at> protonmail.com>:
You have taken responsibility.
(Wed, 05 Feb 2025 09:23:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Pip Cet <pipcet <at> gmail.com>:
bug acknowledged by developer.
(Wed, 05 Feb 2025 09:23:02 GMT)
Full text and
rfc822 format available.
Message #386 received at 36649-done <at> debbugs.gnu.org (full text, mbox):
Commit bf97946d7dc460b7d3c3ce03193041b891b51faf removed purespace,
so I'm closing this bug.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Wed, 05 Mar 2025 12:24:12 GMT)
Full text and
rfc822 format available.
This bug report was last modified 103 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.