unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Lynn Winebarger <owinebar@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Policy on pure space-related fixes
Date: Tue, 2 Aug 2022 02:06:30 -0400	[thread overview]
Message-ID: <CAM=F=bC5yBSHbCQfJ3RPKgTRkDNijYK30u3=C3bhybodrEonPA@mail.gmail.com> (raw)
In-Reply-To: <83czdm688i.fsf@gnu.org>

On Sat, Jul 30, 2022 at 9:27 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Lynn Winebarger <owinebar@gmail.com>
> > Date: Sat, 30 Jul 2022 07:45:21 -0400
> >
> > Generally, are fixes to pure space worth submitting, given the plan to decommission it, or will they just be
> > ignored?  I'm still waiting on clearance from my employer to submit patches, unfortunately.
>
> It depends on the purpose of the change.  If the unexec build is
> broken due to that, we will increase the pure space.  But I don't see
> a reason to do that to cater to a build that we don't yet support, so
> I suggest you do that locally (since you are making a lot of local
> changes anyway).

Now that I have a basic grasp of the bootstrap and dumping process,
I've written a script invoked from my site-load (only during a
non-bootstrap dump) that builds a normal emacs dump in situ, moves
that to emacs-1 (and emacs-1.pdmp), then byte-compiles all the
required files in the site-load.el file using emacs-1 and extracts the
docstrings, before proceeding with the usual build.
It's basically the process Stefan M described for a three stage
bootstrap, but without modifying the configure/Makefiles to make it
happen.
I'm able to run the dump without modifying any lisp files, though I've
made a few modifications to alloc.c to fix the segfaults/runaway
allocation issues, and to lread.c to add a "docstring-hack" variable
so I can explicitly turn off the docstring hack in site-load.el.  I
also have to flip the purify flag off on some of the files that modify
variables declared with defconst.
The build makes it up to the dumping step, at least, but then is
either stuck in a loop of some kind or processing an incredibly large
mark-compact GC algorithm.  I stopped it after a couple of hours.  I'm
going to try adding files in smaller chunks (than the 511 or so I
added) to see where the dumping procedure goes off the rails.
I'm going to try an accurate solution to dealing with cyclic
structures by purecopy as well, to see if I can get rid of the other
segfaults as well.

Lynn



      reply	other threads:[~2022-08-02  6:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-30 11:45 Policy on pure space-related fixes Lynn Winebarger
2022-07-30 13:27 ` Eli Zaretskii
2022-08-02  6:06   ` Lynn Winebarger [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAM=F=bC5yBSHbCQfJ3RPKgTRkDNijYK30u3=C3bhybodrEonPA@mail.gmail.com' \
    --to=owinebar@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).