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).