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

Previous Next

Full log

Message #95 received at 36649 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Pip Cet <pipcet <at> gmail.com>, Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 36649 <at> debbugs.gnu.org, larsi <at> gnus.org, eggert <at> cs.ucla.edu, akrl <at> sdf.org
Subject: Re: bug#36649: 27.0.50; pure space and pdumper
Date: Sun, 15 Nov 2020 07:19:51 -0800

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?

Previous Next

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