memory usage on a sparc

[ted@NMSU.Edu]

   Date: Tue, 26 Nov 91 14:40:13 PST
   From: Jonathan Bachrach <bachrach@aragorn.stanford.edu>

   I read in your documentation that the mach operating system allows
   processes to share text segments and thus, does not severely
   penalize creating additional lisp processes.

that is correct.  mach allows copy on write to work like it should.

   What is the story for the sparc implementation?

sunos supports copy on write as of version 4.0.  unfortunately for the
good guys, when you allocate a copy on write page, swap space is also
allocated.  this means that every user of cmu cl would have to have
nearly 30MB of swap available.  bleah.

   Do separate processes share the read-only portion of the lisp
   image?

yes.  we cheated.

   Any details of how this works would be appreciated.

what we did was map the entire process read only and specify the core
file as the backing file.  we did the same thing with the heap except
that /dev/zero is the backing file.  then as pages are written to,
segmentation violations occur which are caught and repaired by
changing the mapping for that particular page.  this requires swap
space for only the changed pages.

before larry mcvoy moved on to another group at sun, he mentioned that
lazy allocated of swap space for copy on write pages would become
available under sunos.  eager allocation is important to sun since
they use it extensively to improve performance in, among other places,
read.