[Top][All Lists]

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

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

From: Daniel Colascione
Subject: Re: Time to drop the pre-dump phase in the build?
Date: Fri, 10 Jan 2014 19:37:32 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

On 01/10/2014 06:58 PM, Stefan Monnier wrote:
That's why the XEmacs portable dumper is better than the current Emacs
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.

reply via email to

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