Re: Preview: portable dumper

[Daniel Colascione]

On Tue, Nov 29 2016, Stefan Monnier wrote:
>> run.  With a non-PIC executable, you can do a pretty good job of that
>> and get performance a bit better than unexec, in theory.
>
> Got me curious: how/why could it be even better than unexec?

With unexec, we're stuck with whatever heap layout malloc gives us, and
whenever we modify a byte within this heap image, the operating system
has to make a copy of that byte's host page and map that copy back into
our address space. (That is, we take a copy-on-write fault.) Pure
allocation partially, but not completely, addresses this overhead.

With the portable dumper, *we* choose the layout and we can do things
like put strings and other unlikely-to-change bits in part of the file
that probably won't get COW faults.  We also avoid the need to store
malloc data structures.  At runtime, we store the mark bits for objects
in the pdumper image in a contiguous dedicated memory area instead of
mutating the image, further reducing the number of COW faults we need to
incur.  With pdumper and a non-PIC Emacs, you'll only pay for COW faults
on the lisp objects you actually modify.

Even *with* a PIC Emacs (which I hope is the default, because ASLR
greatly improves security), we can get these savings if
mmap(BASE_ADDRESS_STORED_IN_DUMP, ...) succeeds and we can map the dump
where we want.  If we can't map the dump where we want, we'll just
relocate it.

Alternatively, if we're not memory-mapping, we can compress the dump
file --- that's much harder to do with unexec.