Re: Time to drop the pre-dump phase in the build?

[Daniel Colascione <dancol@dancol.org>]

On 01/10/2014 06:58 PM, Stefan Monnier wrote:
>>>> That's why the XEmacs portable dumper is better than the current Emacs
>>>> setup.
>>> Right, a portable dumper would be nice to have.
>>> Tho I don't know enough of the details to know what are the downsides
>>> (e.g. does it require relocation?  If so that means the file can't just
>>> be mmap'd read-only and shared between processes, right?).
>> If I'm reading the XEmacs Internals documentation properly, pdump *may*
>> require relocation, but not if the offset at which the dumpfile is loaded
>> happens to match the offset at which it's loaded. That's about as good as
>> you can ask for.
>
> Which begs the question: when is it the case that the offset matches?
> Can we assume it to be the common case?

Someone who actually uses XEmacs can probably provide better commentary 
(+ Stephen), but I imagine that in a 64-bit address space, you'll pretty 
likely be able to map the dump file in the same place every time. On a 
32-bit system with ASLR, maybe not as often. Cygwin has similar problems 
involving fork.

Another possibility is to just allocate enough space in the emacs image 
itself in BSS, then replace that mapping with a view of the dump file. 
(This way, we always map the dump file at the same place relative to the 
emacs image base). Or we can make the dump file a section in the image, 
but at that point, we're starting to talk about portability problems again.

By the way: is it me, or are we dirtying far too much of the current 
emacs image? On my Emacs, we're dirtying (and COWing) 8MB; if I make 
Fgarbage_collect a no-op, that drops to 4MB.