Re: Loading tramp for dump goes into infinite regress

[Lynn Winebarger <owinebar@gmail.com>]

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

On Tue, Aug 9, 2022, 8:36 AM Po Lu <luangruo@yahoo.com> wrote:

> Lynn Winebarger <owinebar@gmail.com> writes:
>
> > The second statement was comparing dumped versus undumped performance,
> > whether native- or byte- compiled.  This isn't a novel observation,
> > but the dump is basically a one-shot mark-compact GC collection, and
> > the mmap'ed pdump files would ideally be treated like the old
> > generation of a generational collector, and so not traced in most (or
> > all) collection cycles.  This is (or should be) one benefit of pure
> > space, although the requirement that it be read-only could be dropped
> > as long as the write-barrier remains and is used to record any
> > inter-generational pointers to a root set traced by the collector.
>
> This (very) minor benefit of pure space is already gone, since it is
> unprotected and scanned normally for garbage collection in pdumper
> builds.
>


I'm not sure you can conclude that the benefit would be minor when the
non-collected space is a 184MB dump file instead of a fixed pure space that
is 2 or 2.4MB as it is in the standard pdump.
At least some vestiges of the write barrier appear to be in place during
dump mode.  I've had to make a lot of minor corrections of "defconst"
keymaps to defvar, for example due to pure_write_error getting called.
Whether that barrier is uniformly enforced or not is one of the reasons I
suspect this quick hack would not be sufficient.

Lynn

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