Xref: utzoo comp.emacs:4639 gnu.emacs:163
Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!mailrus!bbn!jr@bbn.com
From: jr@bbn.com (John Robinson)
Newsgroups: comp.emacs,gnu.emacs
Subject: Re: Possible to do #undef NO_REMAP for V/386?
Keywords: 386,NO_REMAP
Message-ID: <32238@bbn.COM>
Date: 14 Nov 88 19:12:05 GMT
References: <442@arisia.Xerox.COM>
Sender: news@bbn.COM
Reply-To: jr@bbn.com (John Robinson)
Followup-To: comp.emacs
Organization: BBN Systems and Technologies Corporation, Cambridge MA
Lines: 20
In-reply-to: weikart@arisia.Xerox.COM (Scott Weikart)

In article <442@arisia.Xerox.COM>, weikart@arisia (Scott Weikart) writes:
>Also, it has been suggested that #undef NO_REMAP isn't as important with
>System V release 3, because under Vr3 a new exec shares an existing data
>region, and uses copy on write to replace the data region pages that get
>changed, so that in general there is only one copy of the Emacs libraries in
>memory even if there are multiple Emacses running.  Is this correct?

For this to be true, you still need to load (as in "ld") the libraries
into data space.  So the only difference to do this compared to
existing undump code is whether the pure lisp gets stuffed into text
or data.  Putting it into data will allow some machines to execute
dumped emacs that couldn't before due to mapping restrictions.

Better on machines with shared libraries would be to cons all the
emacs .elc files into a shared library, to which emacs links on
startup.  Anyone working on this approach?  Is it hopeless, given the
rate with which changes to the library components appear?
--
/jr
jr@bbn.com or bbn!jr