Re: /srv/bzr/emacs/emacs-24 r111116: eval-after-load fix

[Stefan Monnier <monnier@iro.umontreal.ca>]

> The arguments that killed purespace for us were (1) most users
> (including most of those who argued for keeping purespace :-) are in
> one-xemacs-process-per-machine workflows, and (2) in theory modern
> virtual memory management by OSes (we were specifically influenced by
> Linux and Windows) should produce most of the benefits of purespace
> anyway, since the dumped code contains only a few writable objects,
> and those tend to be clumped on a very few pages per file, such that
> the potentially written pages might be measured in 100s of KB out of
> the 3-5 MB (at that time) of XEmacs memory.
> I'm not sure I believe (2), though.

I also doubt 2 is true, unless XEmacs's object layout has been changed
to move the markbit out of their objects.  All live objects's markbits
get written during a GC (except for purespace, of course), regardless of
the object being read-only.

But I don't see this sharing as tremendously important: we're talking
about a purespace of about 2MB, for a process whose code size is larger
and whose minimal runtime size is also a good bit larger.
Negligible?  I don't know!  but not terribly important.

OTOH the GC time at start up is reduced by almost a factor 3 (the Lisp
heap size of "emacs -Q" is about 1MB, whereas it'd be around 3MB if it
weren't for the purespace).  On the third hand, this Gnus process has
a Lisp heap size of about 100MB, so the purespace makes virtually no
difference (we'd need a generational GC, instead).



        Stefan