[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Objects that can't be purified during dumping

From: Lynn Winebarger
Subject: Re: Objects that can't be purified during dumping
Date: Sun, 24 Jul 2022 08:16:14 -0400

On Sat, Jul 23, 2022, 11:55 AM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> I recalled seeing an exchange to that effect on this list.   I'll try the
> hack (on alloc.c) and see if it works as an interim solution.

I think you can just do:

    diff --git a/src/alloc.c b/src/alloc.c
    index 6e166d00d5b..acf558f3c7a 100644
    --- a/src/alloc.c
    +++ b/src/alloc.c
    @@ -5611,7 +5611,8 @@ DEFUN ("purecopy", Fpurecopy, Spurecopy, 1, 1, 0,
     static Lisp_Object
     purecopy (Lisp_Object obj)
    -  if (FIXNUMP (obj)
    +  if (true
    +      || FIXNUMP (obj)
           || (! SYMBOLP (obj) && PURE_P (XPNTR (obj)))
           || SUBRP (obj))
         return obj;    /* Already pure.  */

But, the "pinned" approach as is done for hash-tables should work just
fine as well.

I had an off-list response indicating the purify routine is only being called because the ELISP source uses defconst instead of defvar when defining the symbol.  I just changed that statement to a defvar and the problem went away. That's the most expedient solution at the moment, as changing the c source would require re-native-compiling all the elisp files I'm including in the dump, which takes hours to do sequentially.
I will keep this approach in my back pocket for now. Once I know the dump will work, I may revisit the issue.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]