[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Loading tramp for dump goes into infinite regress

From: Lynn Winebarger
Subject: Re: Loading tramp for dump goes into infinite regress
Date: Tue, 9 Aug 2022 09:22:46 -0400

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]