Lynn Winebarger <owinebar@gmail.com> writes:
> 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.
AFAIK we don't officially support any non-standard dump.
I'm not sure how that's relevant, but depending on what you mean by "support", it may not be totally accurate. Aside from providing the option of including site-load and site-init in the system build, there is the user-level function dump-emacs-portable. It's accurate to say the maintainers are not responsible for supporting every random set of libraries put together in a dump. But it's also fair to say that the impact of the system design on nonstandard user dumps is within the remit of the maintainers as a general matter. That said, the priority of such concerns is entirely up to the maintainers.
> 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.
I don't think it's very well enforced. For example, any C code that
calls XSETCAR without checking whether or not the object (i.e. the reuse
argument to Fmatch_end) is writable will result in the invariant being
broken.
True, but if all relevant mutators are effectively contained in lisp.h, the problem of imposing a write barrier would be effectively contained. Then it would just be a matter of determining if the cost of the write barrier being checked at every mutation is paid for by a perceivable reduction in gc-related pauses.
But as I said, it's just a hack I'm tempted to try. I probably won't unless the gc pauses for this mega-dump build become intolerable.
Lynn