unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Policy on pure space-related fixes
@ 2022-07-30 11:45 Lynn Winebarger
  2022-07-30 13:27 ` Eli Zaretskii
  0 siblings, 1 reply; 3+ messages in thread
From: Lynn Winebarger @ 2022-07-30 11:45 UTC (permalink / raw)
  To: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 1649 bytes --]

Hi,
I reported a couple of bugs related to pure space.  One was a duplicate
that had been closed as "won't fix".  The other hasn't gotten any response,
though that could be due to the lack of details.
The one closed as "won't fix" (
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46916) should really be
fixed, even if not by the originally submitted patch.  The response from
Eli that prompted that status was along the lines of "why not just increase
the pure space"?  The answer is: I didn't see any warnings about pure space
being exhausted, even though it turned out I was at least 12MB short.
The fix should just do away with the "small size" increment and allocate
whatever is needed, under the assumption that the user will have to
increase pure space and recompile regardless.  There are too many
assumptions in the code that test purity by distance from the base pure
address to rely on a dump where pure space is exhausted.
The other issue arose from record created by eieio that pun the type of a
class descriptor class to itself.   purecopy does not track cyclic
structures, so diverges and causes a segmentation fault.  I put in a
special case check that prevents the immediate problem, but a real solution
would have to memoize the input structure if the intent of hash consing is
to create singletons and not just read-only constants.  The singleton
property is what seems to be of interest for eieio class descriptor records.
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.

Lynn

[-- Attachment #2: Type: text/html, Size: 1996 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Policy on pure space-related fixes
  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
  0 siblings, 1 reply; 3+ messages in thread
From: Eli Zaretskii @ 2022-07-30 13:27 UTC (permalink / raw)
  To: Lynn Winebarger; +Cc: emacs-devel

> 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).



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Policy on pure space-related fixes
  2022-07-30 13:27 ` Eli Zaretskii
@ 2022-08-02  6:06   ` Lynn Winebarger
  0 siblings, 0 replies; 3+ messages in thread
From: Lynn Winebarger @ 2022-08-02  6:06 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-08-02  6:06 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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

Code repositories for project(s) associated with this 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).