In article <1992Aug17.151311.29507@ods.com> david@ods.com (David Engel) writes:
   william E Davidsen (davidsen@ariel.crd.GE.COM) wrote:
   : In article <1992Aug17.065450.28834@colorado.edu>, drew@ophelia.cs.colorado.edu (Drew Eckhardt) writes:
   : 
   : | Boom.  You've just dirtied that page, and it is no longer 
   : | shareable.  So, instead of having > 200K shared between all
   : | of your shells, you have closer to 800K (Who has less than
   : | 4 shells running at a time).  Not a good thing (tm).
   : 
   :   Well, no, actually. Since the new version of the page is still valid
   : for all processes it would still be sharable. And it would not have to
   : be saved somewhere in the unlikely event that it gets paged out, because
   : the unmodified varsion is still perfectly valid.

   No, it wouldn't be shareable.  When a process writes to a shared page,
   it gets its very own copy of it which is no longer shared.  There is a
   term for this that you probably already know, but others may not.  It's
   called Copy-On-Write.

I think that William and I were thinking in a more theoretical slant.
Yes, the kernel would give each process its own copy if this was done
without guile.  

A brute force technique would be to include a kernel function that
would do the necessary patch and then restore the previous
dirty-status of the page.

Note that with processes sharing the same text, there is even less
overhead, since the patch only happens once per call point per shared
image instead of once per call point per process.

I'm not sure that all this trouble is worth it.  Does anyone have any
hard data on the performance loss of jump tables?

Jay Carlson
nop@theory.cs.mankato.msus.edu