GNU bug report logs - #36649
27.0.50; pure space and pdumper

Previous Next

Full log

View this message in rfc822 format

From: Pip Cet <pipcet <at> gmail.com>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 36649 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, eggert <at> cs.ucla.edu, larsi <at> gnus.org, akrl <at> sdf.org
Subject: bug#36649: 27.0.50; pure space and pdumper
Date: Fri, 28 Aug 2020 12:32:10 +0000

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.